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

Przeglądasz dokumentację Apigee Edge.
Przejdź do Dokumentacja Apigee X. informacje.

InvalidRegularExpression

Komunikat o błędzie

Wdrożenie serwera proxy interfejsu API za pomocą interfejsu Edge UI lub Edge Management API nie powiedzie się i wyświetli się 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.

Przykładowy zrzut ekranu z błędem

Nieprawidłowy tekst wyrażenia regularnego

Przyczyna

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

Diagnostyka

  1. Znajdź nazwę zasady RegularExpressionProtection z komunikatu o błędzie. Na przykład w tym 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 nieprawidłowym kodzie XML zasady ochrony wyrażeń regularnych. Sprawdź, czy w którymś z elementów <Pattern> nie ma nieprawidłowego wyrażenia regularnego. Jeśli którykolwiek z elementów <Pattern> zawiera nieprawidłowe wyrażenie regularne, to to jest 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 w wyrażeniu regularnym określonym w metodzie <Pattern> brakuje nawiasów otwierających. W związku z tym jest ono uznawane za nieprawidłowe wyrażenie regularne. W związku z tym wdrożenie serwera proxy interfejsu API się nie uda.

Rozdzielczość

Upewnij się, że każdy element <Pattern> w zasadzie RegularExpressionProtection zawiera prawidłowe wyrażenie regularne. Możesz wyszukiwać różne narzędzia do debugowania wyrażeń regularnych dostępne online i offline. Aby poprawić przykładową zasadę ochrony przed wyrażeniami regularnymi przedstawioną 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 UI lub Edge Management API nie powiedzie się i wyświetli się 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.

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, ścieżce XPath i prefiksach znajdziesz w artykule Przestrzenie nazw XML i ich wpływ na XPath i CSS.

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 tym 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 z błędami ochrony wyrażenia regularnego sprawdź, czy ścieżka XPath ustawiona w elemencie Expression jest zgodna z ścieżką 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 właściwość <Expression> wskazana w komunikacie o błędzie używa prefiksu lub wartości, która nie jest częścią przestrzeni nazw zadeklarowanych w zasadzie RegularExpressionProtection, jest to przyczyna błędu.

    Zwróć uwagę, że konkretne pole <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>; w związku z tym kompilacja obiektu <XPath> nie uda się i nie uda się wdrożyć.

Rozdzielczość

Sprawdź, czy wszystkie przestrzenie nazw używane w elementach <Expression> w elementach <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 UI lub Edge Management API nie powiedzie się i wyświetli się 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.

Przykładowy zrzut ekranu z błędem

Nie można przekonwertować danych o błędzie „Nie można przekonwertować” na serwer

Przyczyna

Jeśli zasada wyrażeń regularnych zawiera wyrażenie <XPath>, w którym element <Type> jest zdefiniowany jako nodeset, ale nie można go 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 tym 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 z błędami ochrony wyrażenia regularnego sprawdź, czy ścieżka XPath ustawiona w elemencie <Expression> elementu <XPath> jest zgodna ze ścieżką 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> ma wartość nodeset, to jest przyczyną błędu.

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

Rozdzielczość

Jeśli element <Type> jest ustawiony na zbiór węzłów, upewnij się, że wynikiem elementu <Expression> ustawionego w <XPath> jest 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 UI lub Edge Management API nie powiedzie się i wyświetli się 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.

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ę zasady RegularExpressionProtection, w której wystąpił błąd i zostało użyte nieprawidłowe wyrażenie 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 z błędami ochrony wyrażenia regularnego sprawdź, czy ścieżka JSONPath ustawiona w elemencie Expression jest zgodna z ścieżką JSONPath podaną 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, co jest zgodne 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> pod elementem <JSONPath> w zasadzie. Jeśli treść nie jest zgodna ze składnią JSONPath, to jest to przyczyna błędu. W powyższym przykładzie brakuje zamykającego nawiasu kwadratowego, co powoduje, że wyrażenie jest nieprawidłowe.

    Wyrażenie ścieżki JSON jest nieprawidłowe, dlatego nie udało się wdrożyć serwera proxy interfejsu API.

Rozdzielczość

Sprawdź, czy wartość elementu <Expression> w elemencie <JSONPath> w zasadzie ochrony wyrażeń regularnych jest prawidłowym wyrażeniem JSONPath.

Aby poprawić przykład 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 UI lub Edge Management API nie powiedzie się i wyświetli się 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.

Przykładowy zrzut ekranu z błędem

Tekst błędu NothingToEnforce

Przyczyna

Jeśli zasada RegularExpressionProtection nie zawiera żadnego elementu <URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> ani <JSONPayload>, wdrożenie serwera proxy interfejsu API się nie uda.

Jak wskazano w komunikacie o błędzie, zasada ochrony wyrażenia regularnego 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ź niespełnioną zasadę ochrony za pomocą wyrażeń regularnych (podaną 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 te zasady ochrony przed wyrażeniami regularnymi nie zawierają ż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 obowiązkowych 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 UI lub Edge Management API nie powiedzie się i wyświetli się 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.

Przykładowy zrzut ekranu z błędem

NoPatternsToEnforce – tekst błędu

Przyczyna

Jeśli którykolwiek z elementów najwyższego poziomu (<URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> lub <JSONPayload>) nie ma zdefiniowanego elementu <Pattern> w zasadach RegularExpressionProtection, wdrożenie serwera proxy interfejsu API się nie uda.

Diagnostyka

  1. Wskaż 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 tym 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ź, czy zasada ochrony przed wyrażeniami regularnymi narusza zasady, i upewnij się, że element podrzędny wskazany w kroku 1 nie zawiera elementu <Pattern>. Jeśli nie ma w nim elementu <Pattern>, to właśnie jest przyczyną błędu.

    Na przykład ta zasada nie zawiera elementu <Pattern> w elemencie <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 się nie uda.

Rozdzielczość

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

Aby poprawić przykład powyżej, wystarczy dodać element <Pattern> do elementu <XPath> pod nagłówkiem <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 UI lub Edge Management API nie powiedzie się i wyświetli się 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.

Przykładowy zrzut ekranu z błędem

Tekst błędu NONEmptyPrefixMappedToEmptyURI

Przyczyna

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

Diagnostyka

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

    Na przykład w tym błędzie nazwa zasady to Ochrona wyrażenia regularnego 1, a prefiksem jest apigee:

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

  2. W pliku XML z błędami ochrony wyrażenia regularnego sprawdź, czy nazwa prefiksu w elemencie <Namespace> w elemencie <XMLPayload> odpowiada nazwie prefiksu określonej w komunikacie o błędzie (krok 1 powyżej).

    Na przykład ta zasada określa prefiks o nazwie apigee w elemencie <Namespace>, 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>
      <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 prefiksem określonym w kroku 2 ma prawidłowy identyfikator URI. Jeśli brakuje identyfikatora URI, to jest on przyczyną błędu.

    Zwróć uwagę, że w przykładowej zasadzie ochrony wyrażenia regularnego podanej powyżej nie ma identyfikatora URI odpowiadającego elementowi <Namespace> z prefiksem. 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 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 UI lub Edge Management API nie powiedzie się i wyświetli się 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.

Przykładowy zrzut ekranu z błędem

Tekst błędu duplikatu 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>.

Na przykład ten błąd występuje, ponieważ interfejs API prefiksu jest zdefiniowany dwukrotnie w sposób pokazany poniżej: 

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

Diagnostyka

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

    Na przykład w tym błędzie nazwa zasady to Ochrona wyrażenia regularnego 1, a prefiksem jest apigee:

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

  2. W pliku XML z błędami ochrony wyrażenia regularnego sprawdź, czy nazwa prefiksu w elemencie <Namespace> w elemencie <XMLPayload> odpowiada nazwie prefiksu określonej w komunikacie o błędzie (krok 1 powyżej).

    Na przykład ta zasada określa prefiks o nazwie apigee w elemencie <Namespace>, 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>
      <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 zdefiniowane więcej niż raz, to właśnie jest przyczyną błędu.

    Zwróć uwagę na to, że w przykładowej zasadzie ochrony wyrażenia regularnego powyżej zauważono, że element <Namespace> z apigee prefiksu 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 UI lub Edge Management API nie powiedzie się i wyświetli się 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.

Przykładowy zrzut ekranu z błędem

EmptyXPathExpression error text (Tekst błędu EmptyXPathExpression)

Przyczyna

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

Diagnostyka

  1. Zidentyfikuj niedziałającą zasadę ochrony wyrażenia regularnego 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 plik XML zasady ochrony wyrażeń regularnych zawiera nieprawidłowy element <XMLPayload> z elementem podrzędnym <XPath>, 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ładowa 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>

    Element <XPath> 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 <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 UI lub Edge Management API nie powiedzie się i wyświetli się 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.

Przykładowy zrzut ekranu z błędem

Pusty tekst błędu JSONPathExpression

Przyczyna

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

Diagnostyka

  1. Zidentyfikuj niedziałającą zasadę ochrony wyrażenia regularnego 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 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ładowa zasada ochrony 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>