Fehlerbehebung bei der Bereitstellung von Regular Expression Protection-Richtlinien

Sie lesen die Dokumentation zu Apigee X.
Apigee Edge-Dokumentation aufrufen

InvalidRegularExpression

Fehlermeldung

Die Bereitstellung des API-Proxys über die Apigee-Benutzeroberfläche oder die API schlägt mit der folgenden Fehlermeldung fehl:

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.

Beispiel für Fehlermeldung

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.

Beispiel für einen Fehler-Screenshot

Fehlertext "InvalidRegularExpression"

Ursache

Wenn der reguläre Ausdruck im <Pattern>-Element der RegularExpressionProtection-Richtlinie nicht gültig ist, schlägt die Bereitstellung des API-Proxys fehl.

Diagnose

  1. Ermitteln Sie den Namen der RegularExpressionProtection-Richtlinie aus der Fehlermeldung. In der folgenden Fehlermeldung lautet beispielsweise der Name der RegularExpressionProtection-Richtlinie 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. Prüfen Sie alle <Pattern>-Elemente in der fehlgeschlagenen XML-Datei der RegularExpressionProtection-Richtlinie. Prüfen Sie, ob eines der <Pattern>-Elemente einen ungültigen regulären Ausdruck enthält. Wenn eines der <Pattern>-Elemente einen ungültigen regulären Ausdruck hat, ist dies die Ursache des Fehlers.

    Die folgende Richtlinie gibt beispielsweise den Wert Pattern> von foo){2} an, der als ungültiger regulärer Ausdruck betrachtet wird:

    <?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>

    Im Beispiel oben fehlen in dem in <Pattern> angegebenen regulären Ausdruck die öffnenden Klammern. Entsprechend wird er als ungültiger regulärer Ausdruck betrachtet. Die Bereitstellung des API-Proxys schlägt also fehl.

Lösung

Achten Sie darauf, dass jedes <Pattern>-Element in der RegularExpressionProtection-Richtlinie einen gültigen regulären Ausdruck enthält. Sie können nach verschiedenen Online- oder Offline-Regex-Tools suchen, um Fehler in regulären Ausdrücken zu beheben. Fügen Sie die fehlenden Klammern hinzu, um die oben dargestellte Beispielrichtlinie für den regulären Ausdruck zu korrigieren:

<?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

Fehlermeldung

Die Bereitstellung des API-Proxys über die Apigee-Benutzeroberfläche oder die API schlägt mit der folgenden Fehlermeldung fehl:

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.

Beispiel für Fehlermeldung

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.

Beispiel für einen Fehler-Screenshot

Fehlertext "XPathCompilationFailed"

Ursache

Wenn das Präfix oder der Wert, das bzw. der im Element <XPath> verwendet wird, nicht Teil des in der RegularExpressionProtection-Richtlinie deklarierten Namespaces ist, schlägt die Bereitstellung des API-Proxys fehl.

Weitere Informationen zu Namespaces, XPath und Präfixen finden Sie unter XML-Namespaces und ihre Auswirkung auf XPath und XSLT.

Diagnose

  1. Ermitteln Sie den Namen der RegularExpressionProtection-Richtlinie, in der der Fehler aufgetreten ist, sowie den verwendeten XPath-Ausdruck. Sie finden beides in der Fehlermeldung.

    Bei dem folgenden Fehler lautet der Richtlinienname beispielsweise Regular-Expression-Protection-1 und der XPath-Ausdruck /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. Prüfen Sie in der XML-Datei der fehlgeschlagenen Regular Expression Protection-Richtlinie, ob der im Expression-Element festgelegte XPath dem in der Fehlermeldung angegebenen XPath entspricht (Schritt 1 oben).

    Beispiel: Die folgende Richtlinie gibt den XPath als /notapigee:foo/notapigee:bar an, was dem Inhalt der Fehlermeldung entspricht:

    <?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. Prüfen Sie die Elemente <Namespaces> und <Expression> in der RegularExpressionProtection-Richtlinie. Wenn der in der Fehlermeldung angegebene <Expression> ein Präfix oder einen Wert verwendet, der nicht in den in der RegularExpressionProtection-Richtlinie angegebenen Namespaces enthalten ist, ist dies die Ursache des Fehlers.

    Beachten Sie, dass der spezifische <XPath> in der RegularExpressionProtection-Richtlinie das Präfix notapigee verwendet.

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

    Das Präfix notapigee ist jedoch in keinem der <Namespace>-Elemente definiert. Daher führt das Kompilieren von <XPath> zu einem Fehler bei der Bereitstellung.

Lösung

Achten Sie darauf, dass alle Namespaces, die in <Expression>-Elementen unter den <XPath>-Elementen verwendet werden, in der RegularExpressionProtection-Richtlinie deklariert sind. Zur Behebung des obigen Beispiels können Sie das Präfix notapigee durch apigee ersetzen, das in Namespaces deklariert ist:

<?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

Fehlermeldung

Die Bereitstellung des API-Proxys über die Apigee-Benutzeroberfläche oder die API schlägt mit der folgenden Fehlermeldung fehl:

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.

Beispiel für Fehlermeldung

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.

Beispiel für einen Fehler-Screenshot

Fehlertext "CannotBeConvertedToNodeset"

Ursache

Wenn die Regular Expression Protection-Richtlinie einen <XPath>-Ausdruck enthält, bei dem das Element <Type> als nodeset definiert ist, der Ausdruck jedoch nicht in "nodeset" konvertiert werden kann, schlägt die Bereitstellung des API-Proxys fehl.

Diagnose

  1. Ermitteln Sie die RegularExpressionProtection-Richtlinie, in der der Fehler aufgetreten ist, sowie den XPath-Ausdruck, der nicht in "nodeset" konvertiert werden kann. Sie finden beides in der Fehlermeldung.

    Bei dem folgenden Fehler lautet der Richtlinienname beispielsweise Regular-Expression-Protection-1 und der XPath-Ausdruck 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. Prüfen Sie in der XML-Datei der fehlgeschlagenen Regular Expression Protection-Richtlinie, ob der im <Expression>-Element des <XPath>-Elements festgelegte XPath dem in der Fehlermeldung angegebenen XPath entspricht (Schritt 1 oben).

    Beispiel: Die folgende Richtlinie gibt ihn als count(//apigee:foo) an, was dem Inhalt der Fehlermeldung entspricht:

    <?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. Prüfen Sie den im <Type>-Element unter dem Element <XPath> festgelegten Wert. Wenn das <Type>-Element nodeset ist, ist dies die Ursache des Fehlers.

    In diesem Beispiel ist der XPath-Ausdruck count(), der nicht einen oder mehrere Knoten zurückgibt. Die Bereitstellung des API-Proxys schlägt also fehl.

Lösung

Wenn für das Element <Type> ein Knotensatz festgelegt ist, muss das Ergebnis des in <XPath> festgelegten Elements <Expression> mindestens ein Knoten sein. Alternativ können Sie das <Type>-Element entsprechend Ihrem Anwendungsfall auf einen geeigneteren Wert ändern.

Um den Fehler im oben genannte Beispiel zu beheben, können Sie das Element <Expression> auf einen anderen Wert ändern, der Knoten zurückgeben kann:

<?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

Fehlermeldung

Die Bereitstellung des API-Proxys über die Apigee-Benutzeroberfläche oder die API schlägt mit der folgenden Fehlermeldung fehl:

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.

Beispiel für Fehlermeldung

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.

Beispiel für einen Fehler-Screenshot

Fehlertext "JSONPathCompilationFailed"

Ursache

Wenn das <Expression>-Element unter dem <JSONPath>-Element einer Regular Expression Protection-Richtlinie auf einen ungültigen JSONPath-Ausdruck festgelegt ist, schlägt die Bereitstellung des API-Proxys fehl.

Diagnose

  1. Ermitteln Sie den Namen der RegularExpressionProtection-Richtlinie, in der der Fehler aufgetreten ist und der ungültige JSONPath-Ausdruck verwendet wurde. Sie finden beides in der Fehlermeldung.

    Bei dem folgenden Fehler lautet der Richtlinienname beispielsweise Regular-Expression-Protection-1 und der JSONPath-Ausdruck $.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. Prüfen Sie in der XML-Datei der fehlgeschlagenen Regular Expression Protection-Richtlinie, ob der im Expression-Element festgelegte JSONPath dem in der Fehlermeldung angegebenen JSONPath entspricht (Schritt 1 oben).

    Die folgende Richtlinie gibt beispielsweise das Element Expression unter dem Element <JSONPath> als $.store.book[*.author an, was dem Inhalt der Fehlermeldung entspricht:

    <?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. Untersuchen Sie in der Richtlinie das <Expression>-Element unter dem <JSONPath>-Element. Wenn es nicht mit der JSONPath-Syntax übereinstimmt, ist dies die Ursache des Fehlers. Im obigen Beispiel fehlt die schließende eckige Klammer, wodurch der Ausdruck ungültig wird.

    Da der JSONPath-Ausdruck ungültig ist, schlägt die Bereitstellung des API-Proxys fehl.

Lösung

Achten Sie darauf, dass der Wert für das <Expression>-Element innerhalb des <JSONPath>-Elements in der Regular Expression Protection-Richtlinie ein gültiger JSONPath-Ausdruck ist.

Um den Fehler im obigen Beispiel zu korrigieren, können Sie dem Wert des <Expression>-Elements eine schließende eckige Klammer hinzufügen:

<?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

Fehlermeldung

Die Bereitstellung des API-Proxys über die Apigee-Benutzeroberfläche oder die API schlägt mit der folgenden Fehlermeldung fehl:

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

Beispiel für Fehlermeldung

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

Beispiel für einen Fehler-Screenshot

Fehlertext "NothingToForce"

Ursache

Wenn die RegularExpressionProtection-Richtlinie keines der Elemente <URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> oder <JSONPayload> enthält, schlägt die Bereitstellung des API-Proxys fehl.

Wie in der Fehlermeldung angegeben, muss die RegularExpressionProtection-Richtlinie mindestens eines der folgenden Elemente enthalten: <URIPath>, <QueryParam>, <Header>, <FormParam>. <XMLPayload> oder <JSONPayload>.

Diagnose

  1. Ermitteln Sie den Namen der RegularExpressionProtection-Richtlinie, in der der Fehler aufgetreten ist. Sie finden ihn in der Fehlermeldung. Im folgenden Fehler lautet der Richtlinienname beispielsweise Regular-Expression-Protection-1:.

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

  2. Untersuchen Sie die fehlgeschlagene Regular Expression Protection-Richtlinie, die Sie oben in Schritt 1 identifiziert haben. Wenn die Richtlinie keines der Elemente <URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> oder <JSONPayload> enthält, ist dies die Ursache des Fehlers.

    Beispielsweise enthält die folgende Regular Expression Protection-Richtlinie keines der oben genannten Elemente:

    <?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>

    Da keines der erforderlichen Elemente in der Richtlinie für das Extrahieren von Variablen vorhanden ist, schlägt die Bereitstellung des API-Proxys fehl.

Lösung

Die RegularExpressionProtection-Richtlinie muss mindestens eines dieser erforderlichen Elemente enthalten: <URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> oder <JSONPayload>. Beispiel:

<?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

Fehlermeldung

Die Bereitstellung des API-Proxys über die Apigee-Benutzeroberfläche oder die API schlägt mit der folgenden Fehlermeldung fehl:

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

Beispiel für Fehlermeldung

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

Beispiel für einen Fehler-Screenshot

Fehlertext "NoPatternsToForce"

Ursache

Wenn für eines der übergeordneten Elemente (<URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> oder <JSONPayload>) kein <Pattern>-Element in der RegularExpressionProtection-Richtlinie definiert ist, schlägt die Bereitstellung des API-Proxys fehl.

Diagnose

  1. Ermitteln Sie den Namen der RegularExpressionProtection-Richtlinie, in der der Fehler aufgetreten ist, sowie das untergeordnete Element, in dem das Element <Pattern> nicht enthalten ist. Sie finden beides in der Fehlermeldung.

    Beispiel: Im folgenden Fehler lautet der Richtlinienname Regular-Expression-Protection-1, das untergeordnete Element ist XPath:.

    RegularExpressionProtection Regular-Expression-Protection-1: No patterns to enforce in XPath.
  2. Untersuchen Sie die Regular Expression Protection-Richtlinie und prüfen Sie, ob das in Schritt 1 angegebene untergeordnete Element das Element <Pattern> enthält. Wenn das <Pattern>-Element nicht vorhanden ist, ist dies die Ursache des Fehlers.

    Folgende Richtlinie enthält beispielsweise kein <Pattern>-Element in <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>

    Da das <XPath>-Element kein <Pattern>-Element enthält, schlägt die Bereitstellung des API-Proxys fehl.

Lösung

Für jedes der Elemente <URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> oder <JSONPayload> muss mindestens ein <Pattern> angegeben sein. Weitere Informationen zur korrekten Angabe des Elements finden Sie in der RegularExpressionProtection-Richtlinie.

Um den Fehler im obigen Beispiel zu beheben, können wir einfach das Element <Pattern> dem <XPath>-Element unter <XMLPayload> hinzufügen:

<?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

Fehlermeldung

Die Bereitstellung des API-Proxys über die Apigee-Benutzeroberfläche oder die API schlägt mit der folgenden Fehlermeldung fehl:

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

Beispiel für Fehlermeldung

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

Beispiel für einen Fehler-Screenshot

Fehlertext "NONEmptyPrefixMappedToEmptyURI"

Ursache

Dieser Fehler tritt auf, wenn in der RegularExpressionProtection-Richtlinie ein Präfix im <Namespace>-Element unter dem <XMLPayload>-Element definiert ist, aber kein URI.

Diagnose

  1. Ermitteln Sie die RegularExpressionProtection-Richtlinie, in der der Fehler aufgetreten ist, sowie den Namen des Präfixes, das dem URI nicht zugeordnet ist. Sie finden beides in der Fehlermeldung.

    Im folgenden Fehler lautet der Richtlinienname beispielsweise "Regular Expression Protection-1" und das Präfix ist "apigee":

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

  2. Prüfen Sie in der XML-Datei der fehlgeschlagenen Regular Expression Protection-Richtlinie, ob der Name des Präfixes, der im Element <Namespace> unter dem Element <XMLPayload> festgelegt ist, mit dem Präfixnamen aus der Fehlermeldung übereinstimmt (Schritt 1).

    In der folgenden Richtlinie ist beispielsweise ein Präfix namens "apigee" im Element <Namespace> angegeben, das mit dem Inhalt der Fehlermeldung übereinstimmt:

    <?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. Prüfen Sie, ob das <Namespace>-Element mit dem in Schritt 2 angegebenen Präfix einen gültigen URI hat. Wenn der URI fehlt, ist dies die Ursache des Fehlers.

    In der oben beispielhaft aufgeführten Regular Expression Protection-Richtlinie sehen Sie, dass kein URI für das <Namespace>-Element mit dem Präfix "apigee" vorhanden ist. Daher wird folgende Fehlermeldung angezeigt:

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

Lösung

Achten Sie darauf, dass alle <Namespace>-Elemente, für die ein Präfix definiert ist, in der Richtlinie für das Extrahieren von Variablen einen entsprechenden URI haben. Beispiel:

<?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

Fehlermeldung

Die Bereitstellung des API-Proxys über die Apigee-Benutzeroberfläche oder die API schlägt mit der folgenden Fehlermeldung fehl:

Error Saving Revision revision_number
RegularExpressionProtection policy_name: Duplicate prefix prefix_name.

Beispiel für Fehlermeldung

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

Beispiel für einen Fehler-Screenshot

Fehlertext "DuplicatePrefix"

Ursache

Dieser Fehler tritt auf, wenn in der RegularExpressionProtection-Richtlinie im Element <Namespace> unter dem Element <XMLPayload> dasselbe Element mehrmals definiert ist.

Dieser Fehler tritt beispielsweise auf, weil das Apigee-Präfix wie unten dargestellt zweimal definiert ist:

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

Diagnose

  1. Ermitteln Sie die RegularExpressionProtection-Richtlinie, in der der Fehler aufgetreten ist, sowie den Namen des Präfixes. Sie finden beides in der Fehlermeldung.

    Im folgenden Fehler lautet der Richtlinienname beispielsweise "Regular Expression Protection-1" und das Präfix ist "apigee":

    RegularExpressionProtection Regular-Expression-Protection-1: Duplicate prefix apigee.

  2. Prüfen Sie in der XML-Datei der fehlgeschlagenen Regular Expression Protection-Richtlinie, ob der Name des Präfixes, der im Element <Namespace> unter dem Element <XMLPayload> festgelegt ist, mit dem Präfixnamen aus der Fehlermeldung übereinstimmt (Schritt 1).

    In der folgenden Richtlinie ist beispielsweise ein Präfix namens "apigee" im Element <Namespace> angegeben, das mit dem Inhalt der Fehlermeldung übereinstimmt:

    <?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. Ermitteln Sie, ob das <Namespace>-Element mit dem in Schritt 2 angegebenen Präfix mehr als einmal definiert wurde. Wenn es mehrmals definiert ist, ist dies die Ursache des Fehlers.

    Wie Sie in der oben beispielhaft aufgeführten Regular Expression Protection-Richtlinie sehen können, wurde das Element <Namespace> mit dem Präfix Apigee zweimal definiert. Daher wird folgende Fehlermeldung angezeigt:

    Duplicate prefix apigee.

Lösung

Achten Sie darauf, dass in der RegularExpressionProtection-Richtlinie für jedes Präfix in den <Namespace>-Elementen nur eine Definition vorhanden ist. Beispiel:

<?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

Fehlermeldung

Die Bereitstellung des API-Proxys über die Apigee-Benutzeroberfläche oder die API schlägt mit der folgenden Fehlermeldung fehl:

Error Saving Revision revision_number
RegularExpressionProtection policy_name: Empty XPath expression.

Beispiel für Fehlermeldung

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

Beispiel für einen Fehler-Screenshot

Fehlertext "EmptyXPathExpression"

Ursache

Wenn für die RegularExpressionProtection-Richtlinie im Element <XPath> kein <Expression>-Element festgelegt ist, schlägt die Bereitstellung des API-Proxys fehl.

Diagnose

  1. Ermitteln Sie die fehlgeschlagene Regular Expression Protection-Richtlinie aus der Fehlermeldung. Im folgenden Fehler lautet der Richtlinienname beispielsweise "Regular-Expression-Protection-1":

    RegularExpressionProtection Regular-Expression-Protection-1: Empty XPath expression.

  2. Ermitteln Sie in der fehlgeschlagenen XML-Regular Expression Protection-Richtlinie, ob ein <XMLPayload>-Element mit einem <XPath>-Element vorliegt, für das kein <Expression>-Element definiert ist, oder für das Element <Expression> kein Wert festgelegt ist. Wenn ja, ist dies die Ursache des Fehlers.

    Das folgende Beispiel zeigt eine Regular Expression Protection-Richtlinie mit einem <XMLPayload>-Element:

    <?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>

    Da im Element <XPath> ein leeres <Expression>-Element vorhanden ist, schlägt die Bereitstellung des API-Proxys fehl.

Lösung

Achten Sie darauf, dass die RegularExpressionProtection-Richtlinie ein nicht leeres und gültiges <Expression>-Element enthält, das unter dem Element <XPath> definiert ist. Beispiel:

<?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

Fehlermeldung

Die Bereitstellung des API-Proxys über die Apigee-Benutzeroberfläche oder die API schlägt mit der folgenden Fehlermeldung fehl:

Error Saving Revision revision_number
RegularExpressionProtection policy_name: Empty JSONPath expression.

Beispiel für Fehlermeldung

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

Beispiel für einen Fehler-Screenshot

Fehlertext "EmptyJSONPathExpression"

Ursache

Wenn für die RegularExpressionProtection-Richtlinie im Element <JSONPath> kein <Expression>-Element festgelegt ist, schlägt die Bereitstellung des API-Proxys fehl.

Diagnose

  1. Ermitteln Sie die fehlgeschlagene Regular Expression Protection-Richtlinie aus der Fehlermeldung. Im folgenden Fehler lautet der Richtlinienname beispielsweise "Regular-Expression-Protection-1":

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

  2. Ermitteln Sie in der fehlgeschlagenen XML-Regular Expression Protection-Richtlinie, ob ein <JSONPayload>-Element mit einem <JSONPath>-Element vorliegt, für das kein <Expression>-Element definiert ist, oder für das Element <Expression> kein Wert festgelegt ist. Wenn ja, ist dies die Ursache des Fehlers.

    Das folgende Beispiel zeigt eine Regular Expression Protection-Richtlinie mit dem Element <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>

    Da im Element <JSONPath> ein leeres <Expression>-Element vorhanden ist, schlägt die Bereitstellung des API-Proxys fehl.

Lösung

Achten Sie darauf, dass die RegularExpressionProtection-Richtlinie ein nicht leeres und gültiges <Expression>-Element enthält, das unter dem Element <JSONPath> definiert ist. Beispiel:

<?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>