Risoluzione dei problemi relativi agli errori di deployment del criterio di protezione delle espressioni regolari

Stai visualizzando la documentazione di Apigee Edge.
Vai alla sezione Documentazione di Apigee X. Informazioni

InvalidRegularExpression

Messaggio di errore

Il deployment del proxy API tramite la UI o l'API di gestione perimetrale non va a buon fine e questo messaggio di errore:

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.

Messaggio di errore di esempio

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.

Screenshot di errore di esempio

Testo errore Espressione regolare non valida

Causa

Se l'espressione regolare nell'elemento <Pattern> del criterio RegularExpressionProtection non è valida, il deployment del proxy API non va a buon fine.

Diagnosi

  1. Identifica il nome del criterio RegularExpressionProtection dal messaggio di errore. Ad esempio, nell'errore seguente, il nome del criterio RegularExpressionProtection è Regular-Expression-Protection-1:

    Error Deploying Revision 1 to test
RegularExpressionProtection Regular-Expression-Protection-1: Invalid Regular Expression com.apigee.steps.regexprotection.RegularExpressionProtectionBean$RegexPattern@f4ecb23, Context Revision:1;APIProxy:RegexThreat;Organization:myorg;Environment:test.

  2. Esamina tutti gli elementi <Pattern> nel file XML del criterio di protezione dalle espressioni regolari non riuscito. Verifica se uno degli elementi <Pattern> contiene un'espressione regolare non valida. Se uno degli elementi <Pattern> contiene un'espressione regolare non valida, questa è la causa dell'errore.

    Ad esempio, il seguente criterio consente di specificare il valore Pattern> di foo){2}, che è considerato un'espressione regolare non valida: 

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

    Nell'esempio precedente, l'espressione regolare specificata nel campo <Pattern> non contiene parentesi di apertura. Pertanto, viene considerata come un'espressione regolare non valida. Di conseguenza, il deployment del proxy API non va a buon fine.

Risoluzione

Assicurati che ogni elemento <Pattern> del criterio RegularExpressionProtection contenga un'espressione regolare valida. Puoi cercare diversi strumenti regex online o offline per eseguire il debug delle espressioni regolari. Per correggere il criterio di protezione delle espressioni regolari di esempio mostrato sopra, aggiungi le parentesi mancanti:

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

Messaggio di errore

Il deployment del proxy API tramite la UI o l'API di gestione perimetrale non va a buon fine e questo messaggio di errore:

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.

Messaggio di errore di esempio

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.

Screenshot di errore di esempio

Testo di errore XPathCompilationFailed

Causa

Se il prefisso o il valore utilizzato nell'elemento <XPath> non fa parte di nessuno degli spazi dei nomi dichiarati nel criterio RegularExpressionProtection, il deployment del proxy API non riesce.

Puoi trovare ulteriori informazioni su spazi dei nomi, XPath e prefisso in XML Namespaces and How they Affect XPath e TCF.

Diagnosi

  1. Identifica il nome del criterio RegularExpressionProtection in cui si è verificato l'errore e l'espressione XPath utilizzata. Puoi trovare entrambe le voci nel messaggio di errore.

    Ad esempio, nell'errore seguente , il nome del criterio è Regular-Expression-Protection-1 e l'espressione XPath è /notapigee:foo/notapigee:bar:

    Error Deploying Revision 1 to test
RegularExpressionProtection Regular-Expression-Protection-1: Failed to compile xpath /notapigee:foo/notapigee:bar. Context Revision:1;APIProxy:RegexThreat;Organization:myorg;Environment:test.

  2. Nel file XML del criterio di protezione dalle espressioni regolari che non è stato superato, verifica che l'XPath impostato nell'elemento Expression corrisponda all'XPath identificato nel messaggio di errore (passaggio 1 sopra).

    Ad esempio, il seguente criterio specifica l'XPath come /notapigee:foo/notapigee:bar, che corrisponde al contenuto del messaggio di errore:

    <?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. Esamina gli elementi <Namespaces> e <Expression> nel criterio RegularExpressionProtection. Se lo specifico <Expression> indicato nel messaggio di errore utilizza un prefisso o un valore che non fa parte degli spazi dei nomi dichiarati nel criterio RegularExpressionProtection, è questo la causa dell'errore.

    Tieni presente che lo specifico <XPath> utilizza il prefisso notapigee nell'esempio del criterio RegularExpressionProtection:

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

    Tuttavia, il prefisso notapigee non è definito in nessuno degli elementi <Namespace>. pertanto la compilazione di <XPath> non va a buon fine e porta a un errore del deployment.

Risoluzione

Assicurati che tutti gli spazi dei nomi utilizzati negli elementi <Expression> sotto gli elementi <XPath> siano dichiarati nel criterio RegularExpressionProtection. Per correggere l'esempio precedente, puoi sostituire il prefisso notapigee con apigee, che viene dichiarato negli spazi dei nomi:

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

Messaggio di errore

Il deployment del proxy API tramite la UI o l'API di gestione perimetrale non va a buon fine e questo messaggio di errore:

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.

Messaggio di errore di esempio

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.

Screenshot di errore di esempio

Testo dell&#39;errore CanBeConversionsToNodeset

Causa

Se il criterio per le espressioni regolari ha un'espressione <XPath> in cui l'elemento <Type> è definito come nodeset, ma l'espressione non può essere convertita in nodeset, il deployment del proxy API non riuscirà.

Diagnosi

  1. Identifica il criterio RegularExpressionProtection in cui si è verificato l'errore e l'espressione XPath che non può essere convertita in nodeset. Puoi trovare entrambe le voci nel messaggio di errore.

    Ad esempio, nell'errore seguente , il nome del criterio è Regular-Expression-Protection-1 e l'espressione XPath è count(//apigee:foo):

    Error Deploying Revision 1 to test
RegularExpressionProtection Regular-Expression-Protection-1: Result of xpath count(//apigee:foo) cannot be converted to nodeset. Context Revision:1;APIProxy:RegexThreat;Organization:myorg;Environment:test.

  2. Nel file XML del criterio di protezione dalle espressioni regolari con errori, verifica che l'XPath impostato nell'elemento <Expression> dell'elemento <XPath> corrisponda all'XPath identificato nel messaggio di errore (passaggio 1 sopra).

    Ad esempio, il seguente criterio specifica count(//apigee:foo), che corrisponde al contenuto del messaggio di errore:

    <?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. Esamina il valore impostato nell'elemento <Type> sotto l'elemento <XPath>. Se l'elemento <Type> è nodeset, questa è la causa dell'errore.

    In questo esempio, l'espressione XPath è count() che non restituisce uno o più nodi. Pertanto, il deployment del proxy API non va a buon fine.

Risoluzione

Se l'elemento <Type> è impostato su nodeset, assicurati che il risultato dell'elemento <Expression> impostato in <XPath> sia uno o più nodi. In alternativa, modifica l'elemento <Type> impostando un valore più appropriato in base al tuo caso d'uso.

Per correggere l'esempio precedente, potresti modificare l'elemento <Expression> impostando un valore diverso che possa restituire nodi:

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

Messaggio di errore

Il deployment del proxy API tramite la UI o l'API di gestione perimetrale non va a buon fine e questo messaggio di errore:

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.

Messaggio di errore di esempio

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.

Screenshot di errore di esempio

Testo di errore JSONPathCompilationFailed

Causa

Se l'elemento <Expression> in <JSONPath> di un criterio di protezione dalle espressioni regolari è impostato su un'espressione JSONPath non valida, il deployment del proxy API non va a buon fine.

Diagnosi

  1. Identifica il nome del criterio RegularExpressionProtection in cui si è verificato l'errore ed è stata utilizzata l'espressione JSONPath non valida. Puoi trovare entrambe le voci nel messaggio di errore.

    Ad esempio, nell'errore seguente , il nome del criterio è Regular-Expression-Protection-1 e l'espressione JSONPath è $.store.book[*.author:

    Error Deploying Revision 1 to test
RegularExpressionProtection Regular-Expression-Protection-1: Failed to compile jsonpath $.store.book[*.author. Context Revision:1;APIProxy:RegexThreat;Organization:myorg;Environment:test.

  2. Nel file XML del criterio di protezione dalle espressioni regolari con errore, verifica che il set JSONPath impostato nell'elemento Expression corrisponda al JSONPath identificato nel messaggio di errore (passaggio 1 sopra).

    Ad esempio, il seguente criterio specifica l'elemento Expression nell'elemento <JSONPath> come $.store.book[*.author, che corrisponde al contenuto del messaggio di errore:

    <?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. Esamina l'elemento <Expression> all'interno dell'elemento <JSONPath> del criterio. Se non corrisponde alla sintassi di JSONPath, questa è la causa dell'errore. Nell'esempio precedente, manca la parentesi quadra di chiusura e, di conseguenza, l'espressione non è valida.

    Poiché l'espressione di percorso JSON non è valida, il deployment del proxy API ha esito negativo.

Risoluzione

Assicurati che il valore dell'elemento <Expression> all'interno dell'elemento <JSONPath> nel criterio di protezione dalle espressioni regolari sia un'espressione JSONPath valida.

Per correggere l'esempio mostrato sopra, puoi aggiungere la parentesi quadra di chiusura mancante al valore dell'elemento <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

Messaggio di errore

Il deployment del proxy API tramite la UI o l'API di gestione perimetrale non va a buon fine e questo messaggio di errore:

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

Messaggio di errore di esempio

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

Screenshot di errore di esempio

Testo errore NothingToEnforce

Causa

Se il criterio RegularExpressionProtection non contiene gli elementi <URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> o <JSONPayload>, il deployment del proxy API non riesce.

Come indicato nel messaggio di errore, il criterio RegularExpressionProtection deve includere almeno uno dei seguenti elementi: <URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> o <JSONPayload>.

Diagnosi

  1. Identifica il nome del criterio RegularExpressionProtection in cui si è verificato l'errore. Puoi trovarlo nel messaggio di errore. Ad esempio, nell'errore seguente , il nome del criterio è Regular-Expression-Protection-1:

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

  2. Esamina il criterio di protezione delle espressioni regolari che non è stato superato (identificato nel passaggio 1 precedente). Se il criterio non contiene nemmeno uno dei seguenti elementi: <URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> o <JSONPayload>, è questo la causa dell'errore.

    Ad esempio, il seguente criterio di protezione delle espressioni regolari non contiene nessuno degli elementi sopra menzionati:

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

    Poiché nessuno degli elementi obbligatori è presente nel criterio Estrai variabili, il deployment del proxy API non va a buon fine.

Risoluzione

Assicurati che il criterio RegularExpressionProtection abbia almeno uno di questi elementi obbligatori: <URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> o <JSONPayload>. Ad esempio:

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

Messaggio di errore

Il deployment del proxy API tramite la UI o l'API di gestione perimetrale non va a buon fine e questo messaggio di errore:

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

Messaggio di errore di esempio

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

Screenshot di errore di esempio

Testo errore NoPatternsToEnforce

Causa

Se uno degli elementi di primo livello (<URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> o <JSONPayload>) non ha un elemento <Pattern> definito nel criterio RegularExpressionProtection, il deployment del proxy API non va a buon fine.

Diagnosi

  1. Identifica il nome del criterio RegularExpressionProtection in cui si è verificato l'errore e l'elemento secondario che non ha l'elemento <Pattern>. Puoi trovare entrambe le voci nel messaggio di errore.

    Ad esempio, nell'errore seguente, il nome del criterio è Regular-Expression-Protection-1 e l'elemento secondario è XPath:

    RegularExpressionProtection Regular-Expression-Protection-1: No patterns to enforce in XPath.
  2. Esamina il criterio di protezione dalle espressioni regolari non conforme e verifica se l'elemento secondario identificato nel passaggio 1 non dispone dell'elemento <Pattern>. Se l'elemento <Pattern> non esiste al suo interno, questo è la causa dell'errore.

    Ad esempio, il seguente criterio non ha l'elemento <Pattern> all'interno di <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>

    Poiché l'elemento <XPath> non ha l'elemento <Pattern>, il deployment del proxy API non va a buon fine.

Risoluzione

Assicurati che per uno qualsiasi degli elementi <URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> o <JSONPayload> sia specificato almeno un <Pattern>. Consulta il criterio RegularExpressionProtection per informazioni su come specificare correttamente l'elemento.

Per correggere l'esempio riportato sopra, potremmo semplicemente aggiungere l'elemento <Pattern> all'elemento <XPath> sotto <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

Messaggio di errore

Il deployment del proxy API tramite la UI o l'API di gestione perimetrale non va a buon fine e questo messaggio di errore:

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

Messaggio di errore di esempio

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

Screenshot di errore di esempio

Testo errore NONEmptyPrefixMappedToEmptyURI

Causa

Questo errore si verifica se il criterio RegularExpressionProtection ha un prefisso definito nell'elemento <Namespace> sotto l'elemento <XMLPayload>, ma non è definito alcun URI.

Diagnosi

  1. Identifica il criterio RegularExpressionProtection in cui si è verificato l'errore e il nome del prefisso che non è mappato all'URI. Puoi trovare entrambe le voci nel messaggio di errore.

    Ad esempio, nel seguente errore, il nome del criterio è Regular Expression Protection-1 e il prefisso è apigee:

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

  2. Nel file XML del criterio di protezione dalle espressioni regolari con errore, verifica che il nome del prefisso impostato nell'elemento <Namespace> sotto l'elemento <XMLPayload> corrisponda al nome del prefisso identificato nel messaggio di errore (passaggio 1 sopra).

    Ad esempio, il seguente criterio specifica un prefisso denominato apigee nell'elemento <Namespace> , che corrisponde al contenuto del messaggio di errore:

    <?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. Verifica che l'elemento <Namespace> con il prefisso specifico identificato nel passaggio 2 abbia un URI valido. Se manca l'URI, questo è la causa dell'errore.

    Nel criterio di protezione delle espressioni regolari di esempio mostrato sopra, tieni presente che non esiste un URI corrispondente all'elemento <Namespace> con il prefisso apigee; perciò viene visualizzato l'errore:

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

Risoluzione

Assicurati che tutti gli elementi <Namespace> definiti con un prefisso abbiano un URI corrispondente nel criterio Estrai variabili. Ad esempio:

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

Messaggio di errore

Il deployment del proxy API tramite la UI o l'API di gestione perimetrale non va a buon fine e questo messaggio di errore:

Error Saving Revision revision_number
RegularExpressionProtection policy_name: Duplicate prefix prefix_name.

Messaggio di errore di esempio

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

Screenshot di errore di esempio

Testo dell&#39;errore di prefisso duplicato

Causa

Questo errore si verifica se il criterio RegularExpressionProtection ha lo stesso prefisso definito più di una volta nell'elemento <Namespace> sotto l'elemento <XMLPayload>.

Ad esempio, questo errore si verifica perché il prefisso apigee è definito due volte come mostrato di seguito: 

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

Diagnosi

  1. Identifica il criterio RegularExpressionProtection in cui si è verificato l'errore e il nome del prefisso. Puoi trovare entrambe le voci nel messaggio di errore.

    Ad esempio, nel seguente errore, il nome del criterio è Regular Expression Protection-1 e il prefisso è apigee:

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

  2. Nel file XML del criterio di protezione dalle espressioni regolari con errore, verifica che il nome del prefisso impostato nell'elemento <Namespace> sotto l'elemento <XMLPayload> corrisponda al nome del prefisso identificato nel messaggio di errore (passaggio 1 sopra).

    Ad esempio, il seguente criterio specifica un prefisso denominato apigee nell'elemento <Namespace> , che corrisponde al contenuto del messaggio di errore:

    <?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. Determina se l'elemento <Namespace> con il prefisso specifico identificato nel passaggio 2 è stato definito più di una volta. Se viene definito più di una volta, ciò è la causa dell'errore.

    Nel criterio di protezione delle espressioni regolari di esempio mostrato sopra, si noti che l'elemento <Namespace> con il prefisso apigee è stato definito due volte; perciò viene visualizzato l'errore:

    Duplicate prefix apigee.

Risoluzione

Assicurati che esista una sola definizione per ogni prefisso negli elementi <Namespace> del criterio RegularExpressionProtection. Ad esempio:

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

Messaggio di errore

Il deployment del proxy API tramite la UI o l'API di gestione perimetrale non va a buon fine e questo messaggio di errore:

Error Saving Revision revision_number
RegularExpressionProtection policy_name: Empty XPath expression.

Messaggio di errore di esempio

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

Screenshot di errore di esempio

Testo dell&#39;errore EmptyXPathExpression

Causa

Se per il criterio RegularExpressionProtection non è impostato alcun elemento <Expression> all'interno dell'elemento <XPath>, il deployment del proxy API non va a buon fine.

Diagnosi

  1. Identifica il criterio di protezione dalle espressioni regolari non superato dal messaggio di errore. Ad esempio, nell'errore seguente, il nome del criterio è Regular-Expression-Protection-1:

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

  2. Nel file XML del criterio di protezione dalle espressioni regolari non riuscito, determina se è presente un elemento <XMLPayload> con elemento secondario <XPath> in cui non è definito alcun elemento <Expression> o l'elemento <Expression> non è impostato su alcun valore. In tal caso, questa è la causa dell'errore.

    Ad esempio, di seguito è riportato un criterio di protezione dalle espressioni regolari con un elemento <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>

    Poiché è presente un elemento <Expression> vuoto all'interno dell'elemento <XPath>, il deployment del proxy API ha esito negativo.

Risoluzione

Assicurati che il criterio RegularExpressionProtection abbia un elemento <Expression> non vuoto e valido definito sotto l'elemento <XPath>. Ad esempio:

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

Messaggio di errore

Il deployment del proxy API tramite la UI o l'API di gestione perimetrale non va a buon fine e questo messaggio di errore:

Error Saving Revision revision_number
RegularExpressionProtection policy_name: Empty JSONPath expression.

Messaggio di errore di esempio

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

Screenshot di errore di esempio

Testo dell&#39;errore EmptyJSONPathExpression

Causa

Se per il criterio RegularExpressionProtection non è impostato alcun elemento <Expression> all'interno dell'elemento <JSONPath>, il deployment del proxy API non va a buon fine.

Diagnosi

  1. Identifica il criterio di protezione dalle espressioni regolari non superato dal messaggio di errore. Ad esempio, nell'errore seguente, il nome del criterio è Regular-Expression-Protection-1:

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

  2. Nel file XML del criterio di protezione dalle espressioni regolari non riuscito, determina se è presente un elemento <JSONPayload> con elemento secondario <JSONPath> in cui non è definito alcun elemento <Expression> o l'elemento <Expression> non è impostato su alcun valore. In tal caso, questa è la causa dell'errore.

    Ad esempio, ecco un criterio di protezione dalle espressioni regolari con un elemento <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>

    Poiché è presente un elemento <Expression> vuoto all'interno dell'elemento <JSONPath>, il deployment del proxy API ha esito negativo.

Risoluzione

Assicurati che il criterio RegularExpressionProtection abbia un elemento <Expression> non vuoto e valido definito sotto l'elemento <JSONPath>. Ad esempio:

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