Rozwiązywanie problemów z wdrażaniem zasady ochrony wyrażeń regularnych

Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. info

InvalidRegularExpression

Komunikat o błędzie

Wdrożenie serwera proxy interfejsu API za pomocą interfejsu Edge lub interfejsu Edge Management API kończy się niepowodzeniem i wyświetleniem tego komunikatu o błędzie:

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.

Przykładowy komunikat o błędzie

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.

Przykładowy zrzut ekranu z błędem

Tekst błędu InvalidRegularExpression

Przyczyna

Jeśli wyrażenie regularne w elemencie <Pattern> w zasadzie RegularExpressionProtection jest nieprawidłowe, wdrożenie interfejsu Proxy API się nie powiedzie.

Diagnostyka

  1. W komunikacie o błędzie znajdź nazwę zasad ochrony wyrażenia regularnego. Na przykład w tym błędzie nazwa zasad ochrony wyrażenia regularnego to 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. Sprawdź wszystkie elementy <Pattern> w pliku XML zasad ochrony za pomocą wyrażeń regularnych, które nie działają prawidłowo. Sprawdź, czy któryś z elementów <Pattern> zawiera nieprawidłowe wyrażenie regularne. Jeśli którykolwiek z elementów <Pattern> zawiera nieprawidłowe wyrażenie regularne, jest to przyczyną błędu.

    Na przykład ta zasada określa wartość Pattern> argumentu foo){2}, co jest uważane za nieprawidłowe wyrażenie regularne: 

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

    W powyższym przykładzie wyrażenie regularne określone w elementach <Pattern> nie zawiera otwierającego nawiasu. Dlatego jest ono uznawane za nieprawidłowe wyrażenie regularne. Wdrożenie interfejsu API Proxy kończy się niepowodzeniem.

Rozdzielczość

Upewnij się, że każdy element <Pattern> w polityce RegularExpressionProtection zawiera prawidłowe wyrażenie regularne. Aby debugować wyrażenia regularne, możesz wyszukać różne narzędzia do obsługi wyrażeń regularnych online lub offline. Aby poprawić przykład zasad ochrony za pomocą wyrażeń regularnych pokazanych powyżej, dodaj brakujące nawiasy:

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

Komunikat o błędzie

Wdrożenie serwera proxy interfejsu API za pomocą interfejsu Edge lub interfejsu Edge Management API kończy się niepowodzeniem i wyświetleniem tego komunikatu o błędzie:

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.

Przykładowy komunikat o błędzie

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.

Przykładowy zrzut ekranu z błędem

Tekst błędu XPathCompilationFailed

Przyczyna

Jeśli prefiks lub wartość używana w elemencie <XPath> nie należy do żadnej z zadeklarowanych przestrzeni nazw w zasadzie RegularExpressionProtection, wdrożenie serwera proxy interfejsu API się nie uda.

Więcej informacji o przestrzeniach nazw, XPath i prefiksach znajdziesz w artykule Przestrzenie nazw XML i ich wpływ na XPath i XSLT.

Diagnostyka

  1. Określ nazwę zasady RegularExpressionProtection, w której wystąpił błąd, oraz użyte wyrażenie XPath. Oba te elementy znajdziesz w komunikacie o błędzie.

    Na przykład w poniższym błędzie nazwa zasady to Regular-Expression-Protection-1, a wyrażenie XPath to /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. W kodzie XML reguły ochrony za pomocą wyrażeń regularnych, która nie działa prawidłowo, sprawdź, czy ścieżka XPath ustawiona w elemencie Expression jest zgodna ze ścieżką XPath wskazaną w komunikacie o błędzie (krok 1 powyżej).

    Na przykład ta zasada określa ścieżkę XPath jako /notapigee:foo/notapigee:bar, która jest zgodna z treścią komunikatu o błędzie:

    <?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. Sprawdź elementy <Namespaces> i <Expression> w zasadzie RegularExpressionProtection. Jeśli <Expression> wskazany w komunikacie o błędzie używa prefiksu lub wartości, która nie należy do przestrzeni nazw zadeklarowanych w zasadzie ochrony za pomocą wyrażenia regularnego, jest to przyczyna błędu.

    Zwróć uwagę, że w przykładzie zasady <XPath> używającej ochrony wyrażenia regularnego prefiks notapigee:

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

    Jednak prefiks notapigee nie jest zdefiniowany w żadnym z elementów <Namespace>, dlatego kompilacja <XPath> nie powiedzie się i wdrożenie nie powiedzie się.

Rozdzielczość

Upewnij się, że wszystkie przestrzenie nazw używane w elementach <Expression> pod elementami <XPath> są zadeklarowane w zasadzie RegularExpressionProtection. Aby poprawić powyższy przykład, możesz zastąpić prefiks notapigee prefiksem apigee, który jest zadeklarowany w przestrzeniach nazw:

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

Komunikat o błędzie

Wdrożenie serwera proxy interfejsu API za pomocą interfejsu Edge lub interfejsu Edge Management API kończy się niepowodzeniem i wyświetleniem tego komunikatu o błędzie:

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.

Przykładowy komunikat o błędzie

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.

Przykładowy zrzut ekranu z błędem

Tekst błędu CannotBeConvertedToNodeset

Przyczyna

Jeśli zasada wyrażenia regularnego zawiera wyrażenie <XPath>, w którym element <Type> jest zdefiniowany jako nodeset, ale nie można go przekonwertować na nodeset, wdrażanie proxy interfejsu API kończy się niepowodzeniem.

Diagnostyka

  1. Określ zasady RegularExpressionProtection, w których wystąpił błąd, oraz wyrażenie XPath, którego nie można przekonwertować na zestaw węzłów. Oba te elementy znajdziesz w komunikacie o błędzie.

    Na przykład w poniższym błędzie nazwa zasady to Regular-Expression-Protection-1, a wyrażenie XPath to 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. W kodzie XML reguły ochrony za pomocą wyrażeń regularnych, która nie działa, sprawdź, czy ścieżka XPath ustawiona w elemencie <Expression> elementu <XPath> jest zgodna ze ścieżką XPath wskazaną w komunikacie o błędzie (krok 1 powyżej).

    Na przykład w tej regule podany jest parametr count(//apigee:foo), który odpowiada wartości podanej w komunikacie o błędzie:

    <?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. Sprawdź wartość ustawioną w elemencie <Type> pod elementem <XPath>. Jeśli element <Type> ma wartość nodeset, jest to przyczyna błędu.

    W tym przykładzie wyrażenie XPath to count(), które nie zwraca co najmniej 1 węzła. Wdrożenie interfejsu API Proxy się nie powiedzie.

Rozdzielczość

Jeśli element <Type> ma wartość nodeset, sprawdź, czy wyniki elementu <Expression> w elementach <XPath> to co najmniej 1 węzeł. Możesz też zmienić element <Type> na bardziej odpowiednią wartość w zależności od przypadku użycia.

Aby poprawić powyższy przykład, możesz zmienić element <Expression> na inną wartość, która może zwracać węzły:

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

Komunikat o błędzie

Wdrożenie serwera proxy interfejsu API za pomocą interfejsu Edge lub interfejsu Edge Management API kończy się niepowodzeniem i wyświetleniem tego komunikatu o błędzie:

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.

Przykładowy komunikat o błędzie

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.

Przykładowy zrzut ekranu z błędem

Tekst błędu JSONPathCompilationFailed

Przyczyna

Jeśli element <Expression> w elemencie <JSONPath> zasady ochrony wyrażeń regularnych jest ustawiony na nieprawidłowe wyrażenie JSONPath, wdrożenie serwera proxy interfejsu API się nie uda.

Diagnostyka

  1. Określ nazwę polityki RegularExpressionProtection, w której wystąpił błąd i użyto nieprawidłowego wyrażenia JSONPath. Oba te elementy znajdziesz w komunikacie o błędzie.

    Na przykład w poniższym błędzie nazwa zasady to Regular-Expression-Protection-1, a wyrażenie JSONPath to $.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. W pliku XML reguły ochrony za pomocą wyrażeń regularnych, która nie działa prawidłowo, sprawdź, czy ścieżka JSONPath ustawiona w elemencie Expression jest zgodna ze ścieżką JSONPath wskazaną w komunikacie o błędzie (krok 1 powyżej).

    Na przykład w tej polityce element Expression pod elementem <JSONPath> jest określony jako $.store.book[*.author, co odpowiada temu, co jest podane w komunikacie o błędzie:

    <?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. W zasadach sprawdź element <Expression> w elemencie <JSONPath>. Jeśli nie pasuje do składni JSONPath, jest to przyczyna błędu. W powyższym przykładzie brakuje zamykającej nawiasu kwadratowego, przez co wyrażenie jest nieprawidłowe.

    Wyrażenie ścieżki JSON jest nieprawidłowe, więc wdrożenie interfejsu API Proxy kończy się niepowodzeniem.

Rozdzielczość

Upewnij się, że wartość elementu <Expression> w elemencie <JSONPath> w zasadzie ochrony za pomocą wyrażeń regularnych jest prawidłowym wyrażeniem JSONPath.

Aby poprawić powyższy przykład, możesz dodać brakujące nawiasy kwadratowe do wartości elementu <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

Komunikat o błędzie

Wdrożenie serwera proxy interfejsu API za pomocą interfejsu Edge lub interfejsu Edge Management API kończy się niepowodzeniem i wyświetleniem tego komunikatu o błędzie:

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

Przykładowy komunikat o błędzie

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

Przykładowy zrzut ekranu z błędem

Tekst błędu NothingToEnforce

Przyczyna

Jeśli reguła ochrony wyrażenia regularnego nie zawiera żadnego z elementów <URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> ani <JSONPayload>, wdrożenie interfejsu API Proxy kończy się niepowodzeniem.

Jak wskazano w komunikacie o błędzie, zasada RegularExpressionProtection musi zawierać co najmniej 1 z tych elementów: <URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> lub <JSONPayload>.

Diagnostyka

  1. Określ nazwę zasady RegularExpressionProtection, w której wystąpił błąd. Znajdziesz go w komunikacie o błędzie. Na przykład w tym błędzie nazwa zasady to Regular-Expression-Protection-1:

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

  2. Sprawdź niezrealizowane zasady ochrony wyrażeń regularnych (określone w kroku 1 powyżej). Jeśli zasada nie zawiera nawet jednego z tych elementów: <URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> lub <JSONPayload>, to jest przyczyną błędu.

    Na przykład ta zasada ochrony za pomocą wyrażeń regularnych nie zawiera żadnego z wymienionych wyżej elementów:

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

    Ponieważ w zasadzie wyodrębniania zmiennych nie ma żadnych elementów obowiązkowych, wdrożenie serwera proxy interfejsu API się nie powiedzie.

Rozdzielczość

Upewnij się, że zasada RegularExpressionProtection zawiera co najmniej jeden z tych obowiązkowych elementów: <URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> lub <JSONPayload>. Na przykład:

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

Komunikat o błędzie

Wdrożenie serwera proxy interfejsu API za pomocą interfejsu Edge lub interfejsu Edge Management API kończy się niepowodzeniem i wyświetleniem tego komunikatu o błędzie:

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

Przykładowy komunikat o błędzie

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

Przykładowy zrzut ekranu z błędem

Tekst błędu NoPatternsToEnforce

Przyczyna

Jeśli którykolwiek z elementów najwyższego poziomu (<URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> lub <JSONPayload>) nie ma elementu <Pattern> zdefiniowanego w polityce ochrony przed wyrażeniami regularnymi, wdrożenie serwera proxy API zakończy się niepowodzeniem.

Diagnostyka

  1. Określ nazwę zasady RegularExpressionProtection, w której wystąpił błąd, oraz element podrzędny, który nie zawiera elementu <Pattern>. Oba te elementy znajdziesz w komunikacie o błędzie.

    Na przykład w tym błędzie nazwa reguły to Regular-Expression-Protection-1, a element podrzędny to XPath:.

    RegularExpressionProtection Regular-Expression-Protection-1: No patterns to enforce in XPath.
  2. Sprawdź zasadę ochrony za pomocą wyrażeń regularnych, która nie działa prawidłowo, i ustanów, czy element podrzędny zidentyfikowany w kroku 1 nie zawiera elementu <Pattern>. Jeśli element <Pattern> nie istnieje, jest to przyczyna błędu.

    Na przykład ta zasada nie zawiera elementu <Pattern> wewnątrz <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>

    Ponieważ element <XPath> nie zawiera elementu <Pattern>, wdrażanie interfejsu API Proxy się nie powiedzie.

Rozdzielczość

Upewnij się, że każdy z elementów <URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> lub <JSONPayload> ma zdefiniowany co najmniej jeden element <Pattern>. Informacje o prawidłowym określaniu tego elementu znajdziesz w zasadach dotyczących ochrony za pomocą wyrażeń regularnych.

Aby naprawić powyższy przykład, wystarczy dodać element <Pattern> do elementu <XPath> pod elementem <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

Komunikat o błędzie

Wdrożenie serwera proxy interfejsu API za pomocą interfejsu Edge lub interfejsu Edge Management API kończy się niepowodzeniem i wyświetleniem tego komunikatu o błędzie:

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

Przykładowy komunikat o błędzie

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

Przykładowy zrzut ekranu z błędem

Tekst błędu NONEmptyPrefixMappedToEmptyURI

Przyczyna

Ten błąd występuje, jeśli zasada RegularExpressionProtection ma prefiks zdefiniowany w elemencie <Namespace> pod elementem <XMLPayload>, ale nie ma zdefiniowanego URI.

Diagnostyka

  1. Określ zasady ochrony za pomocą wyrażenia regularnego, w których wystąpił błąd, oraz nazwę prefiksu, który nie jest mapowany na identyfikator URI. Oba te elementy znajdziesz w komunikacie o błędzie.

    Na przykład w tym błędzie nazwa reguły to Ochrona za pomocą wyrażenia regularnego-1, a prefiks to apige:

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

  2. W kodzie XML zasady ochrony za pomocą wyrażeń regularnych, która nie działa, sprawdź, czy nazwa prefiksu ustawiona w elemencie <Namespace> pod elementem <XMLPayload> jest zgodna z nazwą prefiksu wskazaną w komunikacie o błędzie (krok 1 powyżej).

    Na przykład w zasadach podano w elemencie <Namespace> prefiks o nazwie apige, który jest zgodny z danymi w komunikacie o błędzie:

    <?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. Sprawdź, czy element <Namespace> z określonym w kroku 2 prefiksem ma prawidłowy identyfikator URI. Jeśli identyfikator URI jest nieprawidłowy, to właśnie on jest przyczyną błędu.

    W powyższym przykładzie reguły ochrony za pomocą wyrażeń regularnych widać, że nie ma identyfikatora URI odpowiadającego elementowi <Namespace> z prefiksem apigee. W związku z tym pojawia się błąd:

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

Rozdzielczość

Upewnij się, że wszystkie elementy <Namespace> zdefiniowane za pomocą prefiksu mają odpowiedni identyfikator URI w zasadach dotyczących wyodrębniania zmiennych. Na przykład:

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

Komunikat o błędzie

Wdrożenie serwera proxy interfejsu API za pomocą interfejsu Edge lub interfejsu Edge Management API kończy się niepowodzeniem i wyświetleniem tego komunikatu o błędzie:

Error Saving Revision revision_number
RegularExpressionProtection policy_name: Duplicate prefix prefix_name.

Przykładowy komunikat o błędzie

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

Przykładowy zrzut ekranu z błędem

DuplicatePrefix błąd tekst

Przyczyna

Ten błąd występuje, jeśli zasada RegularExpressionProtection ma ten sam prefiks zdefiniowany więcej niż raz w elemencie <Namespace> pod elementem <XMLPayload>.

Ten błąd występuje, ponieważ prefiks apigee jest zdefiniowany dwukrotnie, jak pokazano poniżej: 

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

Diagnostyka

  1. Zidentyfikuj zasadę RegularExpressionProtection, w której wystąpił błąd, oraz nazwę prefiksu. Oba te elementy znajdziesz w komunikacie o błędzie.

    Na przykład w tym błędzie nazwa reguły to Ochrona za pomocą wyrażenia regularnego-1, a prefiks to apige:

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

  2. W kodzie XML zasady ochrony za pomocą wyrażeń regularnych, która nie działa, sprawdź, czy nazwa prefiksu ustawiona w elemencie <Namespace> pod elementem <XMLPayload> jest zgodna z nazwą prefiksu wskazaną w komunikacie o błędzie (krok 1 powyżej).

    Na przykład w zasadach podano w elemencie <Namespace> prefiks o nazwie apige, który jest zgodny z danymi w komunikacie o błędzie:

    <?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. Sprawdź, czy element <Namespace> z określonym prefiksem określonym w kroku 2 został zdefiniowany więcej niż raz. Jeśli jest zdefiniowany więcej niż raz, to jest przyczyną błędu.

    W powyższym przykładzie reguły ochrony za pomocą wyrażeń regularnych zwróć uwagę, że element <Namespace> z prefiksem apigee został zdefiniowany dwukrotnie. W związku z tym pojawia się błąd:

    Duplicate prefix apigee.

Rozdzielczość

Upewnij się, że dla każdego prefiksu w elementach <Namespace> w zasadzie RegularExpressionProtection występuje tylko jedna definicja. Na przykład:

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

Komunikat o błędzie

Wdrożenie serwera proxy interfejsu API za pomocą interfejsu Edge lub interfejsu Edge Management API kończy się niepowodzeniem i wyświetleniem tego komunikatu o błędzie:

Error Saving Revision revision_number
RegularExpressionProtection policy_name: Empty XPath expression.

Przykładowy komunikat o błędzie

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

Przykładowy zrzut ekranu z błędem

Tekst błędu EmptyXPathExpression

Przyczyna

Jeśli element <Expression> w elemencie <XPath> w zasadzie RegularExpressionProtection nie zawiera elementu <Expression>, wdrożenie serwera proxy interfejsu API się nie powiedzie.

Diagnostyka

  1. Z komunikatu o błędzie określ, która reguła ochrony za pomocą wyrażeń regularnych nie działa. Na przykład w tym błędzie nazwa reguły to Regular-Expression-Protection-1:

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

  2. W pliku XML reguły Zabezpieczenia za pomocą wyrażenia regularnego, która nie działa prawidłowo, sprawdź, czy zawiera on element <XMLPayload> z elementem podrzędnym <XPath>, który nie ma zdefiniowanego elementu <Expression>, lub czy element <Expression> nie ma przypisanej żadnej wartości. Jeśli tak, to to jest przyczyną błędu.

    Oto na przykład zasada ochrony wyrażeń regularnych, która zawiera element <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>

    Ponieważ wewnątrz elementu <XPath> znajduje się pusty element <Expression>, wdrażanie interfejsu Proxy API kończy się niepowodzeniem.

Rozdzielczość

Upewnij się, że zasada RegularExpressionProtection ma niepusty i prawidłowy element <Expression> zdefiniowany w elemencie <XPath>. Na przykład:

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

Komunikat o błędzie

Wdrożenie serwera proxy interfejsu API za pomocą interfejsu Edge lub interfejsu Edge Management API kończy się niepowodzeniem i wyświetleniem tego komunikatu o błędzie:

Error Saving Revision revision_number
RegularExpressionProtection policy_name: Empty JSONPath expression.

Przykładowy komunikat o błędzie

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

Przykładowy zrzut ekranu z błędem

EmptyJSONPathExpression tekst błędu

Przyczyna

Jeśli w elemencie <JSONPath> w ramach zasad ochrony wyrażenia regularnego nie ma elementu <Expression>, wdrożenie serwera proxy interfejsu API się nie powiedzie.

Diagnostyka

  1. Z komunikatu o błędzie określ, która reguła ochrony za pomocą wyrażeń regularnych nie działa. Na przykład w tym błędzie nazwa reguły to Regular-Expression-Protection-1:

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

  2. Sprawdź, czy plik XML zasady ochrony wyrażeń regularnych zawiera nieprawidłowy element <JSONPayload> z elementem podrzędnym <JSONPath>, który nie ma zdefiniowanego elementu <Expression>, lub czy element <Expression> nie ma żadnej wartości. Jeśli tak, to to jest przyczyną błędu.

    Oto przykład reguły ochrony za pomocą wyrażeń regularnych, która zawiera 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>

    Element <JSONPath> zawiera pusty element <Expression>, dlatego nie udało się wdrożyć serwera proxy interfejsu API.

Rozdzielczość

Upewnij się, że zasada RegularExpressionProtection ma niepusty i prawidłowy element <Expression> zdefiniowany w elemencie <JSONPath>. Na przykład:

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