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

Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje

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świetlany jest ten komunikat 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.

Zrzut ekranu z przykładowym błędem

Tekst błędu NieprawidłoweRegularExpression

Przyczyna

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

Diagnostyka

  1. Sprawdź nazwę zasady RegularExpressionProtection w komunikacie o błędzie. Na przykład w poniższym błędzie nazwa zasady RegularExpressionProtection 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 nieudanym kodzie XML zasad ochrony wyrażeń regularnych. Sprawdź, czy któryś z elementów <Pattern> nie zawiera nieprawidłowego wyrażenia regularnego. Jeśli którykolwiek z elementów <Pattern> ma nieprawidłowe wyrażenie regularne, to właśnie jest przyczyną błędu.

    Na przykład ta zasada określa wartość Pattern> elementu foo){2}, który jest uważany 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 funkcji <Pattern> nie ma nawiasów otwierających. Dlatego jest ono uznawane za nieprawidłowe wyrażenie regularne. W związku z tym wdrożenie serwera proxy interfejsu API kończy się niepowodzeniem.

Rozdzielczość

Upewnij się, że każdy element <Pattern> w zasadzie RegularExpressionProtection zawiera prawidłowe wyrażenie regularne. Do debugowania wyrażeń regularnych możesz wyszukiwać różne narzędzia dostępne online i offline. Aby poprawić przykładową zasadę ochrony wyrażeń regularnych widoczną 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świetlany jest ten komunikat 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.

Zrzut ekranu z przykładowym błędem

Tekst błędu XPathCompilationFailed

Przyczyna

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

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

Diagnostyka

  1. Podaj 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 pliku XML zasad ochrony wyrażeń regularnych, które zakończyły się niepowodzeniem, sprawdź, czy ścieżka XPath ustawiona w elemencie Expression jest zgodna z wartością XPath podaną 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 określona w komunikacie o błędzie wartość <Expression> określona w komunikacie o błędzie zawiera prefiks lub wartość, która nie należy do przestrzeni nazw zadeklarowanych w zasadzie RegularExpressionProtection, to jest to przyczyna błędu.

    Zauważ, że określona zasada <XPath> używa prefiksu notapigee w przykładowej zasadzie RegularExpressionProtection:

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

    Jednak prefiks notapigee nie jest zdefiniowany w żadnym z elementów <Namespace>, dlatego kompilacja obiektu <XPath> kończy się niepowodzeniem wdrożenia.

Rozdzielczość

Sprawdź, czy wszystkie przestrzenie nazw, które są używane w elementach <Expression> w elementach <XPath>, są zadeklarowane w zasadzie RegularExpressionProtection. Aby naprawić powyższy przykład, możesz zastąpić prefiks notapigee ciągiem apigee, który jest zadeklarowany w przestrzeni 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świetlany jest ten komunikat 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.

Zrzut ekranu z przykładowym błędem

Tekst błędu „Nie można przekonwertowaćToNodeset”

Przyczyna

Jeśli zasada wyrażeń regularnych zawiera wyrażenie <XPath>, w którym element <Type> jest zdefiniowany jako zbiór węzłów, ale tego wyrażenia nie można przekonwertować na zbiór węzłów, wdrożenie serwera proxy interfejsu API się nie uda.

Diagnostyka

  1. Określ zasadę RegularExpressionProtection, w której wystąpił błąd, oraz wyrażenie XPath, którego nie można przekonwertować na zbiór 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 pliku XML zasad ochrony wyrażeń regularnych, których nie udało się przetworzyć, sprawdź, czy ścieżka XPath ustawiona w elemencie <Expression> elementu <XPath> jest zgodna z wartością XPath podaną w komunikacie o błędzie (krok 1 powyżej).

    Na przykład ta zasada określa wartość count(//apigee:foo), 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>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> to nodeset, to jest przyczyną błędu.

    W tym przykładzie wyrażenie XPath to count(), które nie zwraca co najmniej jednego węzła. Z tego powodu wdrożenie proxy interfejsu API się nie uda.

Rozdzielczość

Jeśli element <Type> jest ustawiony na zbiór węzłów, upewnij się, że wynik elementu <Expression> ustawionego w <XPath> jest co najmniej 1 węzłem. Możesz też zmienić element <Type> na bardziej odpowiednią wartość na podstawie swojego przypadku użycia.

Aby naprawić powyższy przykład, zmień 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świetlany jest ten komunikat 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.

Zrzut ekranu z przykładowym 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 nie powiedzie się.

Diagnostyka

  1. Znajdź nazwę zasady 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 tym 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 zasad ochrony wyrażeń regularnych, które zakończyły się niepowodzeniem, sprawdź, czy wartość JSONPath ustawiona w elemencie Expression jest zgodna z wartością JSONPath określoną w komunikacie o błędzie (krok 1 powyżej).

    Na przykład ta zasada określa element Expression w elemencie <JSONPath> jako $.store.book[*.author, który jest zgodny 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>
        <JSONPayload>
             <JSONPath>
                 <Expression>$.store.book[*.author</Expression>
                 <Pattern>REGEX PATTERN</Pattern>
                 <Pattern>REGEX PATTERN</Pattern>
             </JSONPath>
            </JSONPayload>
    </RegularExpressionProtection>

  3. Sprawdź element <Expression> w elemencie <JSONPath> w zasadzie. Jeśli nie jest ona zgodna ze składnią JSONPath, to jest przyczyna błędu. W przykładzie powyżej brakuje zamykającego nawiasu kwadratowego, co sprawia, że wyrażenie jest nieprawidłowe.

    Wyrażenie ścieżki JSON jest nieprawidłowe, więc wdrożenie serwera proxy interfejsu API nie powiodło się.

Rozdzielczość

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

Aby poprawić przykład pokazany powyżej, możesz dodać brakujący nawias kwadratowy 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świetlany jest ten komunikat 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.

Zrzut ekranu z przykładowym błędem

Tekst błędu NothingToEnforce

Przyczyna

Jeśli zasada RegularExpressionProtection nie zawiera żadnych elementów <URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> ani <JSONPayload>, wdrożenie serwera proxy interfejsu API nie powiedzie się.

Jak wskazujemy w komunikacie o błędzie, zasada RegularExpressionProtection musi zawierać co najmniej jeden 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 poniższym 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ź nieudaną zasadę ochrony wyrażeń regularnych (opisanych w kroku 1 powyżej). Jeśli zasada nie zawiera nawet jednego z tych elementów: <URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> lub <JSONPayload>, jest to przyczyna błędu.

    Na przykład poniższe zasady ochrony za pomocą wyrażeń regularnych nie zawierają żadnych 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ż zasada Wyodrębnianie zmiennych nie zawiera żadnego z wymaganych elementów, wdrożenie serwera proxy interfejsu API się nie uda.

Rozdzielczość

Upewnij się, że zasada RegularExpressionProtection zawiera co najmniej jeden z tych wymaganych 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świetlany jest ten komunikat 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.

Zrzut ekranu z przykładowym 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 zdefiniowanego elementu <Pattern> w zasadzie RegularExpressionProtection, wdrożenie serwera proxy interfejsu API nie powiedzie się.

Diagnostyka

  1. Określ nazwę zasady RegularExpressionProtection, w której wystąpił błąd, oraz elementu podrzędnego, który nie zawiera elementu <Pattern>. 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 element podrzędny to XPath:

    RegularExpressionProtection Regular-Expression-Protection-1: No patterns to enforce in XPath.
  2. Sprawdź niespełnione zasady ochrony wyrażeń regularnych i upewnij się, że element podrzędny wskazany w kroku 1 nie zawiera elementu <Pattern>. Jeśli element <Pattern> nie istnieje, to jest przyczyną błędu.

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

    Element <XPath> nie zawiera elementu <Pattern>, więc wdrożenie serwera proxy interfejsu API kończy się niepowodzeniem.

Rozdzielczość

Upewnij się, że każdy z elementów <URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> lub <JSONPayload> ma określony co najmniej 1 atrybut <Pattern>. Informacje o tym, jak prawidłowo określić element, znajdziesz w artykule o zasadach RegularExpressionProtection.

Aby poprawić przykład powyżej, możemy dodać element <Pattern> do elementu <XPath> poniżej <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>

NONPusty przedrostek mapowany do pustego identyfikatora URI

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świetlany jest ten komunikat 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.

Zrzut ekranu z przykładowym błędem

Tekst błędu NONEmptyPrefiksMappedToEmptyUuri

Przyczyna

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

Diagnostyka

  1. Określ zasadę RegularExpressionProtection, w której wystąpił błąd, oraz nazwę prefiksu, który nie jest mapowany na identyfikator URI. Oba te elementy znajdziesz w komunikacie o błędzie.

    W poniższym przykładzie w tym błędzie nazwa zasady to Ochrona wyrażeń regularnych 1, a prefiks to apigee:

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

  2. Sprawdź, czy nazwa prefiksu ustawionego w elemencie <Namespace> w elemencie <XMLPayload> w pliku XML zasad ochrony wyrażeń regularnych jest zgodna z nazwą prefiksu podaną w komunikacie o błędzie (krok 1 powyżej).

    Na przykład ta zasada określa w elemencie <Namespace> prefiks o nazwie apigee, który odpowiada 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"/>
          <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> o określonym prefiksie zidentyfikowanym w kroku 2 ma prawidłowy identyfikator URI. Jeśli brakuje identyfikatora URI, jest to przyczyna błędu.

    W przykładowej zasadzie ochrony wyrażeń regularnych opisanej powyżej nie ma identyfikatora URI odpowiadającego elementowi <Namespace> o prefiksie apigee, w związku z czym pojawia się błąd:

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

Rozdzielczość

Sprawdź, czy wszystkie elementy <Namespace> zdefiniowane z prefiksem mają odpowiedni identyfikator URI w zasadzie Wyodrębnianie 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świetlany jest ten komunikat 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.

Zrzut ekranu z przykładowym błędem

Tekst błędu zduplikowanego prefiksu

Przyczyna

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

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

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

Diagnostyka

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

    W poniższym przykładzie w tym błędzie nazwa zasady to Ochrona wyrażeń regularnych 1, a prefiks to apigee:

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

  2. Sprawdź, czy nazwa prefiksu ustawionego w elemencie <Namespace> w elemencie <XMLPayload> w pliku XML zasad ochrony wyrażeń regularnych jest zgodna z nazwą prefiksu podaną w komunikacie o błędzie (krok 1 powyżej).

    Na przykład ta zasada określa w elemencie <Namespace> prefiks o nazwie apigee, który odpowiada 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>
          <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> o określonym prefiksie wskazany w kroku 2 został zdefiniowany więcej niż raz. Jeśli jest ono zdefiniowane więcej niż raz, to jest przyczyną błędu.

    W przedstawionej powyżej przykładowej zasadzie ochrony wyrażeń regularnych zwróć uwagę, że element <Namespace> z prefiksem apigee został zdefiniowany dwukrotnie, dlatego pojawia się błąd:

    Duplicate prefix apigee.

Rozdzielczość

Upewnij się, że każdy prefiks w elementach <Namespace> w zasadzie RegularExpressionProtection ma tylko jedną definicję dla każdego prefiksu. 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świetlany jest ten komunikat 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.

Zrzut ekranu z przykładowym błędem

Tekst błędu EmptyXPathExpression

Przyczyna

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

Diagnostyka

  1. Zidentyfikuj nieudaną zasadę ochrony wyrażeń regularnych na podstawie komunikatu o błędzie. Na przykład w tym błędzie nazwa zasady to: Regular-Expression-Protection-1.

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

  2. Sprawdź, czy w pliku XML zasad ochrony wyrażeń regularnych występuje element <XMLPayload> z elementem podrzędnym <XPath>, który nie ma zdefiniowanego elementu <Expression>, lub czy element <Expression> nie ma ustawionej żadnej wartości. Jeśli tak, to jest jego przyczyna.

    Oto przykładowa zasada ochrony wyrażeń regularnych z 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></Expression>
      <Type>string</Type>
      <Pattern>REGEX PATTERN</Pattern>
    </XPath>
  </XMLPayload>
</RegularExpressionProtection>

    Wdrożenie serwera proxy interfejsu API nie powiodło się, ponieważ w elemencie <XPath> występuje pusty element <Expression>.

Rozdzielczość

Upewnij się, że RegularExpressionProtection (zasada RegularExpressionProtection) w elemencie <XPath> ma zdefiniowany prawidłowy element <Expression> (niepusty i prawidłowy). 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świetlany jest ten komunikat 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.

Zrzut ekranu z przykładowym błędem

Tekst błędu EmptyJSONPathExpression

Przyczyna

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

Diagnostyka

  1. Zidentyfikuj nieudaną zasadę ochrony wyrażeń regularnych na podstawie komunikatu o błędzie. Na przykład w tym błędzie nazwa zasady to: Regular-Expression-Protection-1.

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

  2. Sprawdź, czy w pliku XML zasad ochrony wyrażeń regularnych, które nie zostały spełnione, sprawdź, czy zawiera element <JSONPayload> z elementem podrzędnym <JSONPath>, który nie ma zdefiniowanego elementu <Expression>, lub czy element <Expression> nie ma ustawionej żadnej wartości. Jeśli tak, to jest jego przyczyna.

    Oto przykładowa zasada ochrony wyrażeń regularnych z elementem <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>

    Wdrożenie serwera proxy interfejsu API nie powiodło się, ponieważ w elemencie <JSONPath> występuje pusty element <Expression>.

Rozdzielczość

Upewnij się, że RegularExpressionProtection (zasada RegularExpressionProtection) w elemencie <JSONPath> ma zdefiniowany prawidłowy element <Expression> (niepusty i prawidłowy). 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>