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

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

InvalidRegularExpression

رسالة الخطأ

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

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.

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

نص الخطأ InvalidRegularExpression

السبب

إذا كان التعبير العادي في العنصر <Pattern> من سياسة RegularExpressionProtection غير صالح، سيتعذّر نشر خادم API الوكيل.

التشخيص

  1. حدِّد اسم سياسة RegularExpressionProtection من رسالة الخطأ. على سبيل المثال، في الخطأ التالي، يكون اسم سياسة RegularExpressionProtection هو 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، وتظهر رسالة الخطأ التالية:

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.

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

نص الخطأ XPathCompilationFailed

السبب

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

يمكنك العثور على مزيد من المعلومات حول مساحات الأسماء و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> في سياسة RegularExpressionProtection. إذا كان <Expression> المحدّد في رسالة الخطأ يستخدم بادئة أو قيمة ليست جزءًا من مساحات الأسماء المعرَّفة في سياسة RegularExpressionProtection، سيكون ذلك هو سبب الخطأ.

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

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

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

الدقة

تأكَّد من أنّ جميع مساحات الأسماء المستخدَمة في عناصر <Expression> ضمن عناصر <XPath> معرَّفة في سياسة RegularExpressionProtection. لإصلاح المثال أعلاه، يمكنك استبدال البادئة 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، وتظهر رسالة الخطأ التالية:

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.

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

نص الخطأ CannotBeConvertedToNodeset

السبب

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

التشخيص

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

    على سبيل المثال، في الخطأ التالي، اسم السياسة هو 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> على مجموعة عُقد، تأكَّد من أنّ نتيجة مجموعة العناصر <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، وتظهر رسالة الخطأ التالية:

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 لسياسة "الحماية باستخدام التعبيرات العادية" الذي تعذّر تنفيذه، تأكَّد من أنّ JSONPath الذي تم ضبطه في العنصر Expression يتطابق مع JSONPath المحدّد في رسالة الخطأ (الخطوة رقم 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، وتظهر رسالة الخطأ التالية:

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>

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

الدقة

تأكَّد من أنّ سياسة 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، وتظهر رسالة الخطأ التالية:

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>، يتعذّر نشر خادم وكيل لواجهة برمجة التطبيقات.

الدقة

تأكَّد من أنّ أيًا من العناصر <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، وتظهر رسالة الخطأ التالية:

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). يمكنك العثور على كلتا القيمتين في رسالة الخطأ.

    على سبيل المثال، في الخطأ التالي، اسم السياسة هو Regular Expression Protection-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) يتوافق مع العنصر <Namespace> الذي يتضمّن البادئة apigee، وبالتالي سيظهر لك الخطأ التالي:

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

الدقة

تأكَّد من أنّ جميع عناصر <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="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، وتظهر رسالة الخطأ التالية:

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 التي حدث فيها الخطأ واسم البادئة. يمكنك العثور على كلتا القيمتين في رسالة الخطأ.

    على سبيل المثال، في الخطأ التالي، اسم السياسة هو Regular Expression Protection-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، وتظهر رسالة الخطأ التالية:

Error Saving Revision revision_number
RegularExpressionProtection policy_name: Empty XPath expression.

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

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

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

نص الخطأ EmptyXPathExpression

السبب

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

التشخيص

  1. حدِّد سياسة "الحماية باستخدام التعبيرات العادية" التي تعذّر تنفيذها من رسالة الخطأ. على سبيل المثال، في الخطأ التالي، اسم السياسة هو Regular-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>، يتعذّر نشر خادم وكيل واجهة برمجة التطبيقات.

الدقة

تأكَّد من أنّ سياسة RegularExpressionProtection تتضمّن عنصر <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، وتظهر رسالة الخطأ التالية:

Error Saving Revision revision_number
RegularExpressionProtection policy_name: Empty JSONPath expression.

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

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

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

نص الخطأ EmptyJSONPathExpression

السبب

إذا لم يكن لدى سياسة RegularExpressionProtection أي عنصر <Expression> تم ضبطه ضمن العنصر <JSONPath>، سيتعذّر نشر خادم API الوكيل.

التشخيص

  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>