تحديد المشاكل وحلّها في ما يتعلّق بنشر "سياسة حماية التعبير العادي"

أنت تطّلع على مستندات Apigee Edge.
انتقِل إلى مستندات Apigee X.
info

InvalidRegularExpression

رسالة الخطأ

يتعذّر نشر الوكيل لواجهة برمجة التطبيقات من خلال واجهة مستخدم Edge أو Edge management API مع ظهور رسالة الخطأ التالية:

Error Deploying Revision revision_number to environment
RegularExpressionProtection policy_name: Invalid Regular Expression com.apigee.steps.regexprotection.RegularExpressionProtectionBean$RegexPattern@f4ecb23, Context Revision:revision_number;APIProxy:RegexThreat;Organization:organization;Environment:environment.

مثال على رسالة الخطأ

Error Deploying Revision 1 to test
RegularExpressionProtection Regular-Expression-Protection-1: Invalid Regular Expression com.apigee.steps.regexprotection.RegularExpressionProtectionBean$RegexPattern@f4ecb23, Context Revision:1;APIProxy:RegexThreat;Organization:myorg;Environment:test.

مثال على لقطة شاشة الخطأ

نص الخطأ غيرedUser Expression

السبب

إذا لم يكن التعبير العادي في العنصر <Pattern> ضمن سياسة PrimaryExpressionProtection صالحًا، سيتعذّر نشر الخادم الوكيل لواجهة برمجة التطبيقات.

التشخيص

  1. حدِّد اسم سياسة RegularExpressionProtection من رسالة الخطأ. على سبيل المثال، في الخطأ التالي، يكون اسم PrimaryExpressionProtection هو Regular-Expression-Protection-1:

    Error Deploying Revision 1 to test
    RegularExpressionProtection Regular-Expression-Protection-1: Invalid Regular Expression com.apigee.steps.regexprotection.RegularExpressionProtectionBean$RegexPattern@f4ecb23, Context Revision:1;APIProxy:RegexThreat;Organization:myorg;Environment:test.
    
  2. راجِع جميع عناصر <Pattern> في ملف XML الخاص بسياسة الحماية باستخدام التعبيرات العادية التي تعذّر إكمالها. تحقَّق مما إذا كان أيّ من عناصر <Pattern> يحتوي على تعبير عادي غير صالح. إذا كان أيّ من عناصر <Pattern> يتضمّن تعبيرًا عاديًا غير صالح، هذا هو سبب الخطأ.

    على سبيل المثال، تحدّد السياسة التالية قيمة Pattern> لـ foo){2}، والتي تُعتبر تعبيرًا عاديًا غير صالح:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
        <RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
            <DisplayName>Regular Expression Protection-1</DisplayName>
            <Properties/>
            <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
            <URIPath>
                <Pattern>foo){2}</Pattern>
            </URIPath>
            <Source>request</Source>
        </RegularExpressionProtection>
    

    في المثال أعلاه، لا يتضمّن التعبير العادي المحدّد في <Pattern> قوسًا مفتوحًا. وبالتالي، فهو يُعد تعبيرًا عاديًا غير صالح. وبالتالي، يتعذّر نشر الخادم الوكيل لواجهة برمجة التطبيقات.

الدقة

تأكَّد من أنّ كل عنصر <Pattern> في سياسة RegularExpressionProtection يحتوي على تعبير عادي صالح. يمكنك البحث عن أدوات مختلفة للتعبيرات العادية على الإنترنت أو بلا إنترنت لتصحيح أخطاء التعبيرات العادية. لتصحيح مثال سياسة حماية التعبير العادي المعروض أعلاه، أضِف الأقواس المفقودة:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
        <DisplayName>Regular Expression Protection-1</DisplayName>
        <Properties/>
        <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
        <URIPath>
            <Pattern>(foo){2}</Pattern>
        </URIPath>
        <Source>request</Source>
    </RegularExpressionProtection>

XPathCompilationFailed

رسالة الخطأ

يتعذّر نشر الوكيل لواجهة برمجة التطبيقات من خلال واجهة مستخدم Edge أو Edge management API مع ظهور رسالة الخطأ التالية:

Error Deploying Revision revision_number to environment
RegularExpressionProtection policy_name: Failed to compile xpath xpath_expression. Context Revision:revision_number;APIProxy:RegexThreat;Organization:organization;Environment:environment.

مثال على رسالة الخطأ

Error Deploying Revision 1 to test
RegularExpressionProtection Regular-Expression-Protection-1: Failed to compile xpath /notapigee:foo/notapigee:bar. Context Revision:1;APIProxy:RegexThreat;Organization:myorg;Environment:test.

مثال على لقطة شاشة الخطأ

نص الخطأ XPathCompilationFound

السبب

إذا لم تكن البادئة أو القيمة المستخدمة في العنصر <XPath> جزءًا من أي من مساحات الاسم المعلَن عنها في سياسة PrimaryExpressionProtection، سيتعذّر نشر الخادم الوكيل لواجهة برمجة التطبيقات.

يمكنك العثور على مزيد من المعلومات حول مساحات الأسماء وXPath والبادئة في مقالة مساحات أسماء XML وتأثيرها في XPath وXSLT.

التشخيص

  1. حدِّد اسم سياسة RegularExpressionProtection التي حدث فيها الخطأ وتعبير XPath الذي تم استخدامه. يمكنك العثور على كلا العنصرَين في رسالة الخطأ.

    على سبيل المثال، في الخطأ التالي، يكون اسم السياسة هو Regular-Expression-Protection-1 وتعبير XPath هو /notapigee:foo/notapigee:bar:

    Error Deploying Revision 1 to test
    RegularExpressionProtection Regular-Expression-Protection-1: Failed to compile xpath /notapigee:foo/notapigee:bar. Context Revision:1;APIProxy:RegexThreat;Organization:myorg;Environment:test.
    
  2. في ملف XML لسياسة حماية التعبير العادي الذي تعذّر تحميله، تأكَّد من أنّ مسار XPath الذي تم ضبطه في العنصر Expression يتطابق مع مسار XPath المحدّد في رسالة الخطأ (الخطوة 1 أعلاه).

    على سبيل المثال، تحدّد السياسة التالية مسار XPath على أنّه /notapigee:foo/notapigee:bar الذي يتطابق مع المسار الوارد في رسالة الخطأ:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
        <DisplayName>Regular Expression Protection-1</DisplayName>
        <Properties/>
        <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
        <Source>request</Source>
         <XMLPayload>
             <Namespaces>
                 <Namespace prefix="apigee">http://www.apigee.com</Namespace>
             </Namespaces>
             <XPath>
                 <Expression>/notapigee:foo/notapigee:bar</Expression>
                 <Type>nodeset</Type>
                 <Pattern>pattern</Pattern>
                 <Pattern>pattern2</Pattern>
             </XPath>
         </XMLPayload>
    </RegularExpressionProtection>
    
  3. تحقَّق من العنصرَين <Namespaces> و<Expression> في سياسة PrimaryExpressionProtection. إذا كانت سياسة <Expression> المحدّدة المُشار إليها في رسالة الخطأ تستخدم بادئة أو قيمة ليست جزءًا من مساحات الاسم المحدّدة في سياسة StandardExpressionProtection، يكون هذا هو سبب الخطأ.

    يُرجى ملاحظة أنّ <XPath> المحدّد يستخدم البادئة notapigee في مثال سياسة RegularExpressionProtection:

    <Expression>/notapigee:foo/notapigee:bar</Expression>

    ومع ذلك، لم يتم تعريف البادئة notapigee في أي من عناصر <Namespace>، وبالتالي تعذّر تجميع <XPath> ما أدّى إلى تعذّر النشر.

الدقة

تأكَّد من الإفصاح عن جميع مساحات الاسم المُستخدَمة في عناصر <Expression> ضمن العناصر <XPath> في سياسة GeneralExpressionProtection. لحلّ المشكلة في المثال أعلاه، يمكنك استبدال البادئة notapigee بالبادئة apigee، والتي تمّ الإعلان عنها في مساحات الأسماء:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
    <DisplayName>Regular Expression Protection-1</DisplayName>
    <Properties/>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    <Source>request</Source>
     <XMLPayload>
         <Namespaces>
             <Namespace prefix="apigee">http://www.apigee.com</Namespace>
         </Namespaces>
         <XPath>
             <Expression>/apigee:foo/apigee:bar</Expression>
             <Type>nodeset</Type>
             <Pattern>pattern</Pattern>
             <Pattern>pattern2</Pattern>
         </XPath>
     </XMLPayload>
</RegularExpressionProtection>

CannotBeConvertedToNodeset

رسالة الخطأ

يتعذّر نشر الوكيل لواجهة برمجة التطبيقات من خلال واجهة مستخدم Edge أو Edge management API مع ظهور رسالة الخطأ التالية:

Error Deploying Revision revision_number to environment
RegularExpressionProtection policy_name: Result of xpath xpath_expression cannot be converted to nodeset. Context Revision:revision_number;APIProxy:RegexThreat;Organization:organization;Environment:environment.

مثال على رسالة الخطأ

Error Deploying Revision 1 to test
RegularExpressionProtection Regular-Expression-Protection-1: Result of xpath count(//apigee:foo) cannot be converted to nodeset. Context Revision:1;APIProxy:RegexThreat;Organization:myorg;Environment:test.

مثال على لقطة شاشة الخطأ

نص الخطأ NOTBeConvertToNodeset

السبب

إذا كانت سياسة التعبير العادي تتضمّن تعبيرًا <XPath> يتم فيه تعريف العنصر <Type> على أنّه nodeset، ولكن لا يمكن تحويل التعبير إلى مجموعة_العناصر، سيتعذّر نشر الوكيل لواجهة برمجة التطبيقات.

التشخيص

  1. حدِّد سياسة RegularExpressionProtection التي حدث فيها الخطأ وتعبير XPath الذي لا يمكن تحويله إلى مجموعة عقد. يمكنك العثور على كلا العنصرَين في رسالة الخطأ.

    على سبيل المثال، في الخطأ التالي، اسم السياسة هو Regular-Expression-Protection-1 وتعبير XPath هو count(//apigee:foo):.

    Error Deploying Revision 1 to test
    RegularExpressionProtection Regular-Expression-Protection-1: Result of xpath count(//apigee:foo) cannot be converted to nodeset. Context Revision:1;APIProxy:RegexThreat;Organization:myorg;Environment:test.
    
  2. في ملف XML لسياسة الحماية المستندة إلى التعبير العادي التي تعذّر تطبيقها، تأكَّد من أنّ مسار XPath الذي تم ضبطه في عنصر <Expression> من عنصر <XPath> يتطابق مع مسار XPath المحدّد في رسالة الخطأ (الخطوة 1 أعلاه).

    على سبيل المثال، تحدِّد السياسة التالية القيمة count(//apigee:foo) التي تتطابق مع محتوى رسالة الخطأ:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
        <RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
            <DisplayName>Regular Expression Protection-1</DisplayName>
            <Properties/>
            <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
            <Source>request</Source>
             <XMLPayload>
                 <Namespaces>
                     <Namespace prefix="apigee">http://www.apigee.com</Namespace>
                 </Namespaces>
                 <XPath>
                     <Expression>count(//apigee:foo)</Expression>
                     <Type>nodeset</Type>
                     <Pattern>pattern</Pattern>
                     <Pattern>pattern2</Pattern>
                 </XPath>
             </XMLPayload>
        </RegularExpressionProtection>
    
  3. يمكنك فحص القيمة المضبوطة في العنصر <Type> أسفل العنصر <XPath>. إذا كان عنصر <Type> هو nodeset، هذا هو سبب الخطأ.

    في هذا المثال، تعبير XPath هو count()‎ الذي لا يعرض عقدة واحدة أو أكثر. وبالتالي، يتعذّر نشر "الوكيل لواجهة برمجة التطبيقات".

الدقة

إذا تم ضبط عنصر <Type> على nodeset، تأكَّد من أنّ نتيجة عنصر <Expression> التي تم ضبطها في <XPath> هي عقدة واحدة أو أكثر. بدلاً من ذلك، يمكنك تغيير عنصر <Type> إلى قيمة أكثر ملاءمةً استنادًا إلى حالة الاستخدام.

لحلّ المثال أعلاه، يمكنك تغيير العنصر <Expression> إلى قيمة مختلفة يمكنها عرض العقد:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
    <DisplayName>Regular Expression Protection-1</DisplayName>
    <Properties/>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    <Source>request</Source>
     <XMLPayload>
         <Namespaces>
             <Namespace prefix="apigee">http://www.apigee.com</Namespace>
         </Namespaces>
         <XPath>
             <Expression>/apigee:foo/apigee:bar</Expression>
             <Type>nodeset</Type>
             <Pattern>pattern</Pattern>
             <Pattern>pattern2</Pattern>
         </XPath>
     </XMLPayload>
</RegularExpressionProtection>

JSONPathCompilationFailed

رسالة الخطأ

يتعذّر نشر الوكيل لواجهة برمجة التطبيقات من خلال واجهة مستخدم Edge أو Edge management API مع ظهور رسالة الخطأ التالية:

Error Deploying Revision revision_number to environment
RegularExpressionProtection policy_name: Failed to compile jsonpath jsonpath_expression Context Revision:revision_number;APIProxy:RegexThreat;Organization:organization;Environment:environment.

مثال على رسالة الخطأ

Error Deploying Revision 1 to test
RegularExpressionProtection Regular-Expression-Protection-1: Failed to compile jsonpath $.store.book[*.author. Context Revision:1;APIProxy:RegexThreat;Organization:myorg;Environment:test.

مثال على لقطة شاشة الخطأ

نص الخطأ JSONPathCompilationFailed

السبب

إذا تم ضبط عنصر <Expression> ضمن عنصر <JSONPath> في سياسة "الحماية باستخدام التعبير العادي" على تعبير JSONPath غير صالح، سيتعذّر نشر الوكيل لواجهة برمجة التطبيقات.

التشخيص

  1. حدِّد اسم سياسة RegularExpressionProtection التي حدث فيها الخطأ وتم فيها استخدام تعبير JSONPath غير الصالح. يمكنك العثور على كلا العنصرَين في رسالة الخطأ.

    على سبيل المثال، في الخطأ التالي، اسم السياسة هو Regular-Expression-Protection-1 وتعبير JSONPath هو $.store.book[*.author:.

    Error Deploying Revision 1 to test
    RegularExpressionProtection Regular-Expression-Protection-1: Failed to compile jsonpath $.store.book[*.author. Context Revision:1;APIProxy:RegexThreat;Organization:myorg;Environment:test.
    
  2. في ملف XML الخاص بسياسة "الحماية من التعبيرات العادية" التي تعذّر تطبيقها، تأكّد من أنّ مسار JSON الذي تم ضبطه في العنصر Expression يتطابق مع مسار JSON المحدّد في رسالة الخطأ (الخطوة 1 أعلاه).

    على سبيل المثال، تحدّد السياسة التالية عنصر Expression ضمن عنصر <JSONPath> على أنّه $.store.book[*.author، ما يتطابق مع ما ورد في رسالة الخطأ:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
        <RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
            <DisplayName>Regular Expression Protection-1</DisplayName>
            <Properties/>
            <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
            <Source>request</Source>
            <JSONPayload>
                 <JSONPath>
                     <Expression>$.store.book[*.author</Expression>
                     <Pattern>REGEX PATTERN</Pattern>
                     <Pattern>REGEX PATTERN</Pattern>
                 </JSONPath>
                </JSONPayload>
        </RegularExpressionProtection>
    
  3. راجِع عنصر <Expression> ضمن عنصر <JSONPath> في السياسة. إذا لم يتطابق مع بنية JSONPath، هذا هو سبب الخطأ. في المثال أعلاه، لا يتوفّر القوس المربّع المغلق، ما يجعل التعبير غير صالح.

    بما أنّ تعبير مسار JSON غير صالح، يتعذّر نشر "الوكيل لواجهة برمجة التطبيقات".

الدقة

تأكَّد من أنّ قيمة العنصر <Expression> داخل العنصر <JSONPath> في "سياسة حماية التعبير العادي" هي تعبير JSONPath صالح.

لتصحيح المثال المعروض أعلاه، يمكنك إضافة قوس مربّع إغلاق غير متوفّر إلى قيمة عنصر <Expression>:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
    <DisplayName>Regular Expression Protection-1</DisplayName>
    <Properties/>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    <Source>request</Source>
    <JSONPayload>
         <JSONPath>
             <Expression>$.store.book[*].author</Expression>
             <Pattern>REGEX PATTERN</Pattern>
             <Pattern>REGEX PATTERN</Pattern>
         </JSONPath>
        </JSONPayload>
</RegularExpressionProtection>

NothingToEnforce

رسالة الخطأ

يتعذّر نشر الوكيل لواجهة برمجة التطبيقات من خلال واجهة مستخدم Edge أو Edge management API مع ظهور رسالة الخطأ التالية:

Error Saving Revision revision_number
RegularExpressionProtection policy_name: at least one of URIPath, QueryParam, Header, FormParam, XMLPayload, JSONPayload is mandatory.

مثال على رسالة الخطأ

Error Saving Revision 1
RegularExpressionProtection Regular-Expression-Protection-1: at least one of URIPath, QueryParam, Header, FormParam, XMLPayload, JSONPayload is mandatory.

مثال على لقطة شاشة الخطأ

نص الخطأ NothingToEnforce

السبب

إذا لم تتضمّن سياسة RegularExpressionProtection أيًا من العناصر <URIPath> أو <QueryParam> أو <Header> أو <FormParam> أو <XMLPayload> أو <JSONPayload>، سيتعذّر نشر وكيل واجهة برمجة التطبيقات.

كما هو موضّح في رسالة الخطأ، يجب أن تتضمّن سياسة RegularExpressionProtection عنصرًا واحدًا على الأقل من هذه العناصر: <URIPath> أو <QueryParam> أو <Header> أو <FormParam> أو <XMLPayload> أو <JSONPayload>.

التشخيص

  1. حدِّد اسم سياسة RegularExpressionProtection التي حدث فيها الخطأ. يمكنك العثور عليه في رسالة الخطأ. على سبيل المثال، في الخطأ التالي، اسم السياسة هو Regular-Expression-Protection-1:.

    RegularExpressionProtection Regular-Expression-Protection-1: at least one of URIPath, QueryParam, Header, FormParam, XMLPayload, JSONPayload is mandatory.
    
  2. فحص سياسة "حماية التعبير العادي" التي لم يتم اجتيازها (تم تحديدها في الخطوة رقم 1 أعلاه). إذا لم تتضمّن السياسة أيًا من العناصر التالية: <URIPath> أو <QueryParam> أو <Header> أو <FormParam> أو <XMLPayload> أو <JSONPayload>، هذا هو سبب الخطأ.

    على سبيل المثال، لا تتضمن سياسة الحماية من التعبير العادي التالية أيًّا من العناصر المذكورة أعلاه:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
        <RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
            <DisplayName>Regular Expression Protection-1</DisplayName>
            <Properties/>
            <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
            <Source>request</Source>
        </RegularExpressionProtection>
    

    بما أنّه لا يتوفّر أيّ من العناصر الإلزامية في سياسة استخراج المتغيّرات، يتعذّر نشر الوكيل لواجهة برمجة التطبيقات.

الدقة

تأكَّد من أنّ سياسة حماية الحقوق العادية تحتوي على أحد هذه العناصر الإلزامية على الأقل: <URIPath> أو <QueryParam> أو <Header> أو <FormParam> أو <XMLPayload> أو <JSONPayload>. على سبيل المثال:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
    <DisplayName>Regular Expression Protection-1</DisplayName>
    <Properties/>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    <Source>request</Source>
    <JSONPayload>
        <JSONPath>
            <Expression>$.store.book[*].author</Expression>
            <Pattern>REGEX PATTERN</Pattern>
            <Pattern>REGEX PATTERN</Pattern>
        </JSONPath>
    </JSONPayload>
</RegularExpressionProtection>

NoPatternsToEnforce

رسالة الخطأ

يتعذّر نشر الوكيل لواجهة برمجة التطبيقات من خلال واجهة مستخدم Edge أو Edge management API مع ظهور رسالة الخطأ التالية:

Error Saving Revision revision_number
RegularExpressionProtection policy_name: No patterns to enforce in payload_name.

مثال على رسالة الخطأ

Error Saving Revision 1
RegularExpressionProtection Regular-Expression-Protection-1: No patterns to enforce in XPath.

مثال على لقطة شاشة الخطأ

نص الخطأ NoPatternsToEnforce

السبب

إذا لم يكن لأيّ من عناصر المستوى الأعلى (<URIPath> أو <QueryParam> أو <Header> أو <FormParam> أو <XMLPayload> أو <JSONPayload>) عنصر <Pattern> محدّدًا في سياسة RegularExpressionProtection، سيتعذّر نشر الوكيل لواجهة برمجة التطبيقات.

التشخيص

  1. حدِّد اسم سياسة RegularExpressionProtection التي حدث فيها الخطأ والعنصر الفرعي الذي لا يحتوي على العنصر <Pattern>. يمكنك العثور على كلا هذين العنصرَين في رسالة الخطأ.

    على سبيل المثال، في الخطأ التالي، اسم السياسة هو Regular-Expression-Protection-1 والعنصر الثانوي هو XPath:.

    RegularExpressionProtection Regular-Expression-Protection-1: No patterns to enforce in XPath.
    
  2. راجِع سياسة "الحماية من التعبيرات العادية" التي تؤدي إلى حدوث خطأ وتأكَّد مما إذا كان العنصر الفرعي الذي تم تحديده في الخطوة 1 لا يحتوي على العنصر <Pattern>. في حال عدم توفّر عنصر <Pattern> فيه، يكون هذا هو سبب الخطأ.

    على سبيل المثال، لا تحتوي السياسة التالية على عنصر <Pattern> داخل <XPath>:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
        <RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
          <DisplayName>Regular Expression Protection-1</DisplayName>
          <Properties/>
          <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
          <Source>request</Source>
          <XMLPayload>
            <Namespaces>
              <Namespace prefix="apigee">http://www.apigee.com</Namespace>
            </Namespaces>
            <XPath>
              <Expression>/apigee:Greeting/apigee:User</Expression>
              <Type>string</Type>
            </XPath>
          </XMLPayload>
        </RegularExpressionProtection>
    

    بما أنّ عنصر <XPath> لا يحتوي على عنصر <Pattern>، يتعذّر نشر خادم API الوكيل.

الدقة

تأكَّد من أنّ أيًا من العناصر <URIPath> أو <QueryParam> أو <Header> أو <FormParam> أو <XMLPayload> أو <JSONPayload> يتضمّن <Pattern> واحدًا على الأقل. اطّلِع على سياسة RegularExpressionProtection للحصول على معلومات عن كيفية تحديد العنصر بشكل صحيح.

لحلّ المثال أعلاه، يمكننا ببساطة إضافة العنصر <Pattern> إلى العنصر <XPath> أسفل <XMLPayload>:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
  <DisplayName>Regular Expression Protection-1</DisplayName>
  <Properties/>
  <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  <Source>request</Source>
  <XMLPayload>
    <Namespaces>
      <Namespace prefix="apigee">http://www.apigee.com</Namespace>
    </Namespaces>
    <XPath>
      <Expression>/apigee:Greeting/apigee:User</Expression>
      <Type>string</Type>
      <Pattern>REGEX PATTERN</Pattern>
    </XPath>
  </XMLPayload>
</RegularExpressionProtection>

NONEmptyPrefixMappedToEmptyURI

رسالة الخطأ

يتعذّر نشر الوكيل لواجهة برمجة التطبيقات من خلال واجهة مستخدم Edge أو Edge management API مع ظهور رسالة الخطأ التالية:

Error Saving Revision revision_number
RegularExpressionProtection policy_name: Non-empty prefix prefix_name cannot be mapped to empty uri.

مثال على رسالة الخطأ

Error Saving Revision 1
RegularExpressionProtection Regular-Expression-Protection-1: Non-empty prefix apigee cannot be mapped to empty uri.

مثال على لقطة شاشة للخطأ

نص الخطأ NONEmptyPrefixMappedToEmptyURI

السبب

يحدث هذا الخطأ إذا كانت سياسة RegularExpressionProtection تحتوي على بادئة محدّدة في عنصر <Namespace> ضمن عنصر <XMLPayload>، ولكن لم يتم تحديد معرّف موارد منتظم (URI).

التشخيص

  1. حدِّد سياسة RegularExpressionProtection التي حدث فيها الخطأ واسم البادئة التي لم تتم ربطها بمعرّف الموارد المنتظم (URI). يمكنك العثور على كلا هذين العنصرَين في رسالة الخطأ.

    على سبيل المثال، في الخطأ التالي، اسم السياسة هو "الحماية باستخدام التعبير العادي-1" والبادئة هي apigee:

    RegularExpressionProtection Regular-Expression-Protection-1: Non-empty prefix apigee cannot be mapped to empty uri.
    
  2. في ملف XML لسياسة الحماية باستخدام التعبيرات العادية الذي تعذّر تحميله، تأكّد من أنّ اسم البادئة المحدّد في عنصر <Namespace> ضمن عنصر <XMLPayload> يتطابق مع اسم البادئة المحدّد في رسالة الخطأ (الخطوة 1 أعلاه).

    على سبيل المثال، تحدّد السياسة التالية بادئة باسم apigee في عنصر <Namespace>، ما يتطابق مع ما ورد في رسالة الخطأ:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
        <RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
          <DisplayName>Regular Expression Protection-1</DisplayName>
          <Properties/>
          <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
          <Source>request</Source>
          <XMLPayload>
            <Namespaces>
              <Namespace prefix="apigee"/>
              <Namespace prefix="gmail">http://mail.google.com</Namespace>
            </Namespaces>
            <XPath>
              <Expression>/apigee:Greeting/apigee:User</Expression>
              <Type>string</Type>
              <Pattern>REGEX PATTERN</Pattern>
            </XPath>
          </XMLPayload>
        </RegularExpressionProtection>
    
  3. تحقَّق مما إذا كان العنصر <Namespace> الذي يتضمّن البادئة المحدَّدة في الخطوة رقم 2 يتضمّن معرّف موارد منتظم (URI) صالح. إذا لم يكن معرّف URI متوفّرًا، هذا هو سبب الخطأ.

    في مثال سياسة حماية التعبير العادي الموضّح أعلاه، يُرجى ملاحظة أنّه ما مِن عنوان URL يتوافق مع عنصر <Namespace> الذي يحتوي على البادئة apigee، وبالتالي يظهر لك الخطأ التالي:

    Non-empty prefix apigee cannot be mapped to empty uri.

الدقة

تأكَّد من أنّ جميع عناصر <Namespace> المحدّدة ببادئة لها معرّف موارد منتظم (URI) مطابق في سياسة استخراج المتغيرات. على سبيل المثال:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
  <DisplayName>Regular Expression Protection-1</DisplayName>
  <Properties/>
  <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  <Source>request</Source>
  <XMLPayload>
    <Namespaces>
      <Namespace prefix="apigee">http://www.apigee.com</Namespace>
      <Namespace prefix="gmail">http://mail.google.com</Namespace>
    </Namespaces>
    <XPath>
      <Expression>/apigee:Greeting/apigee:User</Expression>
      <Type>string</Type>
      <Pattern>REGEX PATTERN</Pattern>
    </XPath>
  </XMLPayload>
</RegularExpressionProtection>

DuplicatePrefix

رسالة الخطأ

يتعذّر نشر الوكيل لواجهة برمجة التطبيقات من خلال واجهة مستخدم Edge أو Edge management API مع ظهور رسالة الخطأ التالية:

Error Saving Revision revision_number
RegularExpressionProtection policy_name: Duplicate prefix prefix_name.

مثال على رسالة الخطأ

Error Saving Revision 1
RegularExpressionProtection Regular-Expression-Protection-1: Duplicate prefix apigee.

مثال على لقطة شاشة الخطأ

نص خطأ DuplicatePrefix

السبب

يحدث هذا الخطأ إذا كانت سياسة RegularExpressionProtection تحتوي على البادئة نفسها المحدّدة أكثر من مرّة في عنصر <Namespace> ضمن عنصر <XMLPayload>.

على سبيل المثال، يحدث هذا الخطأ لأنّه تم تعريف البادئة apigee مرتين كما هو موضّح أدناه:

<Namespace prefix="apigee">http://www.apigee.com</Namespace>
<Namespace prefix="apigee">http://www.apigee.com</Namespace>

التشخيص

  1. حدِّد سياسة RegularExpressionProtection التي حدث فيها الخطأ واسم البادئة. يمكنك العثور على كلا العنصرَين في رسالة الخطأ.

    على سبيل المثال، في الخطأ التالي، اسم السياسة هو "الحماية باستخدام التعبير العادي-1" والبادئة هي apigee:

    RegularExpressionProtection Regular-Expression-Protection-1: Duplicate prefix apigee.
    
  2. في ملف XML لسياسة الحماية باستخدام التعبيرات العادية الذي تعذّر تحميله، تأكّد من أنّ اسم البادئة المحدّد في عنصر <Namespace> ضمن عنصر <XMLPayload> يتطابق مع اسم البادئة المحدّد في رسالة الخطأ (الخطوة 1 أعلاه).

    على سبيل المثال، تحدّد السياسة التالية بادئة باسم apigee في عنصر <Namespace>، ما يتطابق مع ما ورد في رسالة الخطأ:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
        <RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
          <DisplayName>Regular Expression Protection-1</DisplayName>
          <Properties/>
          <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
          <Source>request</Source>
          <XMLPayload>
            <Namespaces>
              <Namespace prefix="apigee">http://www.apigee.com</Namespace>
              <Namespace prefix="apigee">http://www.apigee.com</Namespace>
            </Namespaces>
            <XPath>
              <Expression>/apigee:Greeting/apigee:User</Expression>
              <Type>string</Type>
              <Pattern>REGEX PATTERN</Pattern>
            </XPath>
          </XMLPayload>
        </RegularExpressionProtection>
    
  3. حدِّد ما إذا تم تحديد عنصر <Namespace> الذي يتضمّن البادئة المحدّدة في الخطوة 2 أكثر من مرّة. إذا تم تحديده أكثر من مرة، هذا هو سبب الخطأ.

    في مثال سياسة حماية التعبير العادي الموضّح أعلاه، لاحظ أنّه تمّ تعريف العنصر <Namespace> مع البادئة apigee مرّتين، وبالتالي تظهر لك رسالة الخطأ التالية:

    Duplicate prefix apigee.
    

الدقة

تأكَّد من توفّر تعريف واحد فقط لكل بادئة في عناصر <Namespace> ضمن سياسة RegularExpressionProtection. على سبيل المثال:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
      <DisplayName>Regular Expression Protection-1</DisplayName>
      <Properties/>
      <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
      <Source>request</Source>
      <XMLPayload>
        <Namespaces>
          <Namespace prefix="apigee">http://www.apigee.com</Namespace>
        </Namespaces>
        <XPath>
          <Expression>/apigee:Greeting/apigee:User</Expression>
          <Type>string</Type>
          <Pattern>REGEX PATTERN</Pattern>
        </XPath>
      </XMLPayload>
    </RegularExpressionProtection>

EmptyXPathExpression

رسالة الخطأ

يتعذّر نشر الوكيل لواجهة برمجة التطبيقات من خلال واجهة مستخدم Edge أو Edge management API مع ظهور رسالة الخطأ التالية:

Error Saving Revision revision_number
RegularExpressionProtection policy_name: Empty XPath expression.

مثال على رسالة الخطأ

Error Saving Revision 1
RegularExpressionProtection Regular-Expression-Protection-1: Empty XPath expression.

مثال على لقطة شاشة الخطأ

نص الخطأ BlankXPathexpression

السبب

إذا لم تتضمّن سياسة RegularExpressionProtection عنصر <Expression> تم ضبطه ضمن عنصر <XPath>، سيتعذّر نشر الوكيل لواجهة برمجة التطبيقات.

التشخيص

  1. يمكنك تحديد سياسة حماية التعبير العادي التي تعذّر تطبيقها من رسالة الخطأ. على سبيل المثال، في الخطأ التالي، يكون اسم السياسة هو Standard-Expression-Protection-1:

    RegularExpressionProtection Regular-Expression-Protection-1: Empty XPath expression.
    
  2. في ملف XML لسياسة "الحماية من التعبيرات العادية" التي تعذّر إكمالها، حدِّد ما إذا كان هناك عنصر <XMLPayload> يتضمّن عنصرًا فرعيًا <XPath> لا يحتوي على عنصر <Expression> محدّد فيه، أو ما إذا لم يتم ضبط عنصر <Expression> على أي قيمة. إذا كان الأمر كذلك، هذا هو سبب الخطأ.

    على سبيل المثال، في ما يلي سياسة حماية التعبير العادي التي تحتوي على عنصر <XMLPayload>:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
      <DisplayName>Regular Expression Protection-1</DisplayName>
      <Properties/>
      <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
      <Source>request</Source>
      <XMLPayload>
        <Namespaces>
          <Namespace prefix="apigee">http://www.apigee.com</Namespace>
        </Namespaces>
        <XPath>
          <Expression></Expression>
          <Type>string</Type>
          <Pattern>REGEX PATTERN</Pattern>
        </XPath>
      </XMLPayload>
    </RegularExpressionProtection>
    

    بما أنّ هناك عنصر <Expression> فارغًا داخل عنصر <XPath>، يتعذّر نشر "وكيل واجهة برمجة التطبيقات".

الدقة

تأكَّد من أنّ سياسة PrimaryExpressionProtection تتضمّن عنصر <Expression> غير فارغ وصالح تم تحديده ضمن العنصر <XPath>. على سبيل المثال:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
  <DisplayName>Regular Expression Protection-1</DisplayName>
  <Properties/>
  <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  <Source>request</Source>
  <XMLPayload>
    <Namespaces>
      <Namespace prefix="apigee">http://www.apigee.com</Namespace>
    </Namespaces>
    <XPath>
      <Expression>/apigee:Greeting/apigee:User</Expression>
      <Type>string</Type>
      <Pattern>REGEX PATTERN</Pattern>
    </XPath>
  </XMLPayload>
</RegularExpressionProtection>

EmptyJSONPathExpression

رسالة الخطأ

يتعذّر نشر الوكيل لواجهة برمجة التطبيقات من خلال واجهة مستخدم Edge أو Edge management API مع ظهور رسالة الخطأ التالية:

Error Saving Revision revision_number
RegularExpressionProtection policy_name: Empty JSONPath expression.

مثال على رسالة الخطأ

Error Saving Revision 1
RegularExpressionProtection Regular-Expression-Protection-1: Empty JSONPath expression.

مثال على لقطة شاشة الخطأ

نص خطأ EmptyJSONPathExpression

السبب

إذا لم يتم ضبط العنصر <Expression> داخل العنصر <JSONPath> في PrimaryExpressionProtection، لن يتم نشر الخادم الوكيل لواجهة برمجة التطبيقات.

التشخيص

  1. يمكنك تحديد سياسة حماية التعبير العادي التي تعذّر تطبيقها من رسالة الخطأ. على سبيل المثال، في الخطأ التالي، اسم السياسة هو Regular-Expression-Protection-1:

    Error Saving Revision 1
    RegularExpressionProtection Regular-Expression-Protection-1: Empty JSONPath expression.
    
  2. في ملف XML الخاص بسياسة حماية التعبير العادي التي تعذّر إكمالها، حدِّد ما إذا كان هناك عنصر <JSONPayload> يتضمّن عنصرًا فرعيًا <JSONPath> لا يحتوي على عنصر <Expression> محدّد فيه، أو لم يتم ضبط عنصر <Expression> على أي قيمة. إذا كان الأمر كذلك، هذا هو سبب الخطأ.

    على سبيل المثال، في ما يلي سياسة حماية التعبير العادي التي تحتوي على عنصر <JSONPayload>:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
        <RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
          <DisplayName>Regular Expression Protection-1</DisplayName>
          <Properties/>
          <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
          <Source>request</Source>
          <JSONPayload>
            <JSONPath>
              <Expression></Expression>
              <Pattern>REGEX PATTERN</Pattern>
              <Pattern>REGEX PATTERN</Pattern>
            </JSONPath>
          </JSONPayload>
        </RegularExpressionProtection>
    

    بما أنّ هناك عنصر <Expression> فارغًا داخل عنصر <JSONPath>، يتعذّر نشر "وكيل واجهة برمجة التطبيقات".

الدقة

تأكَّد من أنّ سياسة RegularExpressionProtection تحتوي على عنصر <Expression> صالح وغير فارغ تم تحديده ضمن عنصر <JSONPath>. على سبيل المثال:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
  <DisplayName>Regular Expression Protection-1</DisplayName>
  <Properties/>
  <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  <Source>request</Source>
  <JSONPayload>
    <JSONPath>
      <Expression>$.store.book[*].author</Expression>
      <Pattern>REGEX PATTERN</Pattern>
      <Pattern>REGEX PATTERN</Pattern>
    </JSONPath>
  </JSONPayload>
</RegularExpressionProtection>