Résolution des erreurs de déploiement de la règle de protection des expressions régulières

Vous consultez la documentation d'Apigee et d'Apigee hybrid.
Consultez la documentation d'Apigee Edge.

InvalidRegularExpression

Message d'erreur

Le déploiement du proxy d'API par le biais de l'interface utilisateur ou l'API Apigee échoue avec le message d'erreur suivant :

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.

Exemple de message d'erreur

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.

Exemple de capture d'écran d'erreur

Texte d'erreur InvalidRegularExpression

Cause

Si l'expression régulière de l'élément <Pattern> de la règle RegularExpressionProtection n'est pas valide, le déploiement du proxy d'API échoue.

Diagnostic

  1. Identifiez le nom de la règle RegularExpressionProtection dans le message d'erreur. Par exemple, dans l'erreur suivante, le nom de la règle RegularExpressionProtection est 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. Examinez tous les éléments <Pattern> dans le fichier XML la règle de protection contre les expressions régulières défaillante. Vérifiez si l'un des éléments <Pattern> comporte une expression régulière non valide. Si l'un des éléments <Pattern> comporte une expression régulière non valide, il s'agit de la cause de l'erreur.

    Par exemple, la règle suivante spécifie la valeur Pattern> de foo){2}, qui est considérée comme une expression régulière non valide :

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

    Dans l'exemple ci-dessus, il manque une parenthèse d'ouverture dans l'expression régulière spécifiée dans l'élément <Pattern>. Elle est donc considérée comme une expression régulière non valide. Par conséquent, le déploiement du proxy d'API échoue.

Solution

Assurez-vous que chaque élément <Pattern> dans la règle RegularExpressionProtection contient une expression régulière valide. Vous pouvez rechercher différents outils d'expression régulière en ligne ou hors connexion pour déboguer vos expressions régulières. Pour corriger l'exemple de protection contre les expressions régulières ci-dessus, ajoutez la parenthèse manquante :

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

Message d'erreur

Le déploiement du proxy d'API par le biais de l'interface utilisateur ou l'API Apigee échoue avec le message d'erreur suivant :

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.

Exemple de message d'erreur

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.

Exemple de capture d'écran d'erreur

Texte d&#39;erreur XPathCompilationFailed

Cause

Si le préfixe ou la valeur utilisée dans l'élément <XPath> ne fait partie d'aucun des espaces de noms déclarés dans la règle RegularExpressionProtection, le déploiement du proxy d'API échoue.

Pour en savoir plus sur les espaces de noms, les chemins XPath et le préfixe, reportez-vous à la section Les espaces de noms XML et comment ils affectent XPath et XHTML.

Diagnostic

  1. Identifiez le nom de la règle RegularExpressionProtection dans laquelle l'erreur s'est produite et l'expression XPath utilisée. Ces deux éléments se trouvent dans le message d'erreur.

    Par exemple, dans l'erreur suivante, le nom de la règle est Regular-Expression-Protection-1 et l'expression XPath est /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. Dans le fichier XML de la règle de protection des expressions régulières défaillante, vérifiez que le chemin XPath défini dans l'élément Expression correspond au chemin XPath identifié dans le message d'erreur (étape 1 ci-dessus).

    Par exemple, la règle suivante spécifie XPath comme /notapigee:foo/notapigee:bar, ce qui correspond au contenu du message d'erreur :

    <?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. Examinez les éléments <Namespaces> et <Expression> dans la règle RegularExpressionProtection. Si l'élément <Expression> spécifique indiqué dans le message d'erreur utilise un préfixe ou une valeur qui ne fait pas partie des espaces de noms déclarés dans la règle RegularExpressionProtection, il s'agit de la cause de l'erreur.

    Notez que le fichier <XPath> spécifique utilise le préfixe notapigee dans l'exemple de règle RegularExpressionProtection :

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

    Cependant, le préfixe notapigee n'est défini dans aucun des éléments <Namespace>. Par conséquent, la compilation de <XPath> échoue, ce qui entraîne l'échec du déploiement.

Solution

Vérifiez que tous les espaces de noms utilisés dans les éléments <Expression> sous les éléments <XPath> sont déclarés dans la règle RegularExpressionProtection. Pour corriger l'exemple ci-dessus, vous pouvez remplacer le préfixe notapigee par apigee, qui est déclaré dans les espaces de noms :

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

Message d'erreur

Le déploiement du proxy d'API par le biais de l'interface utilisateur ou l'API Apigee échoue avec le message d'erreur suivant :

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.

Exemple de message d'erreur

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.

Exemple de capture d'écran d'erreur

Texte d&#39;erreur CannotBeConvertedToNodeset

Cause

Si la règle d'expression régulière contient une expression <XPath> où l'élément <Type> est défini sur nodeset, mais que l'expression ne peut pas être convertie en ensemble de nœuds, le déploiement du proxy d'API échoue.

Diagnostic

  1. Identifiez la règle RegularExpressionProtection dans laquelle l'erreur s'est produite et l'expression XPath ne pouvant pas être convertie en ensemble de nœuds. Ces deux éléments se trouvent dans le message d'erreur.

    Par exemple, dans l'erreur suivante, le nom de la règle est Regular-Expression-Protection-1 et l'expression XPath est 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. Dans le fichier XML de la règle de protection des expressions régulières défaillante, vérifiez que le chemin XPath défini dans l'élément <Expression> de l'élément <XPath> correspond au chemin XPath identifié dans le message d'erreur (étape 1 ci-dessus).

    Par exemple, la règle suivante spécifie count(//apigee:foo), ce qui correspond au contenu du message d'erreur :

    <?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. Examinez la valeur définie dans l'élément <Type> sous l'élément <XPath>. Si l'élément <Type> est nodeset, il s'agit de la cause de l'erreur.

    Dans cet exemple, l'expression XPath est count(), qui ne renvoie pas un ou plusieurs nœuds. Par conséquent, le déploiement du proxy d'API échoue.

Solution

Si l'élément <Type> est défini sur "nodeset", assurez-vous que le résultat de l'élément <Expression> défini dans <XPath> est un ou plusieurs nœuds. Vous pouvez également remplacer l'élément <Type> par une valeur plus appropriée en fonction de votre cas d'utilisation.

Pour corriger l'exemple ci-dessus, vous pouvez remplacer l'élément <Expression> par une valeur différente capable de renvoyer des nœuds :

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

Message d'erreur

Le déploiement du proxy d'API par le biais de l'interface utilisateur ou l'API Apigee échoue avec le message d'erreur suivant :

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.

Exemple de message d'erreur

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.

Exemple de capture d'écran d'erreur

Texte d&#39;erreur JSONPathCompilationFailed

Cause

Si l'élément <Expression> sous l'élément <JSONPath> d'une règle de protection contre les expressions régulières est défini sur une expression JSONPath non valide, le déploiement du proxy d'API échoue.

Diagnostic

  1. Identifiez le nom de la règle RegularExpressionProtection dans laquelle l'erreur s'est produite et l'expression JSONPath non valide qui a été utilisée. Ces deux éléments se trouvent dans le message d'erreur.

    Par exemple, dans l'erreur suivante, le nom de la règle est Regular-Expression-Protection-1 et l'expression JSONPath est $.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. Dans le fichier XML de la règle de protection des expressions régulières défaillante, vérifiez que le chemin JSONPath défini dans l'élément Expression correspond au chemin JSONPath identifié dans le message d'erreur (étape 1 ci-dessus).

    Par exemple, la règle suivante spécifie l'élément Expression sous l'élément <JSONPath> comme $.store.book[*.author, ce qui correspond au contenu du message d'erreur :

    <?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. Examinez l'élément <Expression> sous l'élément <JSONPath> dans la règle. S'il ne correspond pas à la syntaxe JSONPath, il s'agit de la cause de l'erreur. Dans l'exemple ci-dessus, le crochet fermant est manquant, ce qui rend l'expression non valide.

    Comme l'expression de chemin JSON n'est pas valide, le déploiement du proxy d'API échoue.

Solution

Vérifiez que la valeur de l'élément <Expression> dans l'élément <JSONPath> de la règle de protection contre les expressions régulières est une expression JSONPath valide.

Pour corriger l'exemple ci-dessus, vous pourriez ajouter le crochet fermant manquant à la valeur de l'élément <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

Message d'erreur

Le déploiement du proxy d'API par le biais de l'interface utilisateur ou l'API Apigee échoue avec le message d'erreur suivant :

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

Exemple de message d'erreur

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

Exemple de capture d'écran d'erreur

Texte d&#39;erreur NothingToEnforce

Cause

Si la règle RegularExpressionProtection ne comporte aucun des éléments <URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> ou <JSONPayload>, le déploiement du proxy d'API échoue.

Comme indiqué dans le message d'erreur, la règle RegularExpressionProtection doit comporter au moins l'un de ces éléments inclus dans la règle : <URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> ou <JSONPayload>.

Diagnostic

  1. Identifiez le nom de la règle RegularExpressionProtection dans laquelle l'erreur s'est produite. Il se trouve dans le message d'erreur. Par exemple, dans l'erreur suivante, le nom de la règle est Regular-Expression-Protection-1:

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

  2. Examinez la règle de protection des expressions régulières défaillante (identifiée à l'étape 1 ci-dessus). Si la règle ne comporte pas l'un des éléments suivants : <URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> ou <JSONPayload>, il s'agit de la cause de l'erreur.

    Par exemple, la règle suivante de protection des expressions régulières ne contient aucun des éléments mentionnés ci-dessus :

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

    Comme aucun des éléments obligatoires n'est présent dans la règle d'extraction de variables ExtractVariables, le déploiement du proxy d'API échoue.

Solution

Vérifiez que la règle RegularExpressionProtection comporte au moins l'un des éléments obligatoires suivants : <URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> ou <JSONPayload>. Exemple :

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

Message d'erreur

Le déploiement du proxy d'API par le biais de l'interface utilisateur ou l'API Apigee échoue avec le message d'erreur suivant :

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

Exemple de message d'erreur

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

Exemple de capture d'écran d'erreur

Texte d&#39;erreur NoPatternsToEnforce

Cause

Si l'un des éléments de premier niveau (<URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> ou <JSONPayload>) ne comporte pas d'élément <Pattern> défini dans la règle RegularExpressionProtection, le déploiement du proxy d'API échoue.

Diagnostic

  1. Identifiez le nom de la règle RegularExpressionProtection dans laquelle l'erreur s'est produite, ainsi que l'élément enfant qui ne comporte pas l'élément <Pattern>. Ces deux éléments se trouvent dans le message d'erreur.

    Par exemple, dans l'erreur suivante, le nom de la règle est Regular-Expression-Protection-1 et l'élément enfant est XPath:.

    RegularExpressionProtection Regular-Expression-Protection-1: No patterns to enforce in XPath.
  2. Examinez la règle de protection des expressions régulières défaillante et vérifiez si l'élément enfant identifié à l'étape 1 ne contient pas l'élément <Pattern>. Si l'élément <Pattern> n'y figure pas, il s'agit de la cause de l'erreur.

    Par exemple, la règle suivante ne comporte pas d'élément <Pattern> dans <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>

    Comme l'élément <XPath> ne comporte pas l'élément <Pattern>, le déploiement du proxy d'API échoue.

Solution

Assurez-vous que les éléments <URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> ou <JSONPayload> contiennent au moins un élément <Pattern> spécifié. Consultez la section Règle RegularExpressionProtection pour savoir comment spécifier correctement l'élément.

Pour corriger l'exemple ci-dessus, nous pourrions simplement ajouter l'élément <Pattern> à l'élément <XPath> sous <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

Message d'erreur

Le déploiement du proxy d'API par le biais de l'interface utilisateur ou l'API Apigee échoue avec le message d'erreur suivant :

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

Exemple de message d'erreur

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

Exemple de capture d'écran d'erreur

Texte d&#39;erreur NONEmptyPrefixMappedToEmptyURI

Cause

Cette erreur se produit si la règle RegularExpressionProtection comporte un préfixe défini dans l'élément <Namespace> sous l'élément <XMLPayload>, mais qu'aucun URI n'est défini.

Diagnostic

  1. Identifiez la règle RegularExpressionProtection dans laquelle l'erreur s'est produite et le nom du préfixe non mappé sur l'URI. Ces deux éléments se trouvent dans le message d'erreur.

    Par exemple, dans l'erreur suivante, le nom de la règle est Regular Expression Protection-1 et le préfixe est apigee :

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

  2. Dans le fichier XML de la règle de protection des expressions régulières défaillante, vérifiez que le nom du préfixe défini dans l'élément <Namespace> sous l'élément <XMLPayload> correspond au nom du préfixe identifié dans le message d'erreur (étape 1 ci-dessus).

    Par exemple, la règle suivante spécifie un préfixe nommé apigee dans l'élément <Namespace>, ce qui correspond au contenu du message d'erreur :

    <?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. Validez si l'élément <Namespace> avec le préfixe spécifique identifié à l'étape 2 possède un URI valide. Si l'URI est manquant, il s'agit de la cause de l'erreur.

    Dans l'exemple de règle de protection des expressions régulières ci-dessus, notez qu'aucun URI ne correspond à l'élément <Namespace> portant le préfixe apigee. Vous obtenez donc l'erreur suivante :

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

Solution

Assurez-vous que tous les éléments <Namespace> définis avec un préfixe ont un URI correspondant dans la règle d'extraction de variables ExtractVariables. Exemple :

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

Message d'erreur

Le déploiement du proxy d'API par le biais de l'interface utilisateur ou l'API Apigee échoue avec le message d'erreur suivant :

Error Saving Revision revision_number
RegularExpressionProtection policy_name: Duplicate prefix prefix_name.

Exemple de message d'erreur

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

Exemple de capture d'écran d'erreur

Texte d&#39;erreur DuplicatePrefix

Cause

Cette erreur se produit si la règle RegularExpressionProtection a le même préfixe défini plusieurs fois dans l'élément <Namespace> sous l'élément <XMLPayload>.

Par exemple, cette erreur se produit car le préfixe apigee est défini deux fois, comme indiqué ci-dessous :

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

Diagnostic

  1. Identifiez la règle RegularExpressionProtection dans laquelle l'erreur s'est produite et le nom du préfixe. Ces deux éléments se trouvent dans le message d'erreur.

    Par exemple, dans l'erreur suivante, le nom de la règle est Regular Expression Protection-1 et le préfixe est apigee :

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

  2. Dans le fichier XML de la règle de protection des expressions régulières défaillante, vérifiez que le nom du préfixe défini dans l'élément <Namespace> sous l'élément <XMLPayload> correspond au nom du préfixe identifié dans le message d'erreur (étape 1 ci-dessus).

    Par exemple, la règle suivante spécifie un préfixe nommé apigee dans l'élément <Namespace>, ce qui correspond au contenu du message d'erreur :

    <?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. Déterminez si l'élément <Namespace> avec le préfixe spécifique, identifié à l'étape 2, a été défini plus d'une fois. S'il est défini plus d'une fois, alors il s'agit de la cause de l'erreur.

    Dans l'exemple de règle de protection des expressions régulières ci-dessus, notez que l'élément <Namespace> portant le préfixe apigee a été défini deux fois. Vous obtenez donc l'erreur suivante :

    Duplicate prefix apigee.

Solution

Assurez-vous qu'une seule définition existe pour chaque préfixe dans les éléments <Namespace> de la règle RegularExpressionProtection. Exemple :

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

Message d'erreur

Le déploiement du proxy d'API par le biais de l'interface utilisateur ou l'API Apigee échoue avec le message d'erreur suivant :

Error Saving Revision revision_number
RegularExpressionProtection policy_name: Empty XPath expression.

Exemple de message d'erreur

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

Exemple de capture d'écran d'erreur

Texte d&#39;erreur EmptyXPathExpression

Cause

Si la règle RegularExpressionProtection ne contient pas d'élément <Expression> défini dans l'élément <XPath>, le déploiement du proxy d'API échoue.

Diagnostic

  1. Identifiez la règle de protection des expressions régulières défaillante à partir du message d'erreur. Par exemple, dans l'erreur suivante, le nom de la règle est Regular-Expression-Protection-1 :

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

  2. Dans le fichier XML de la règle de protection des expressions régulières défaillante, déterminez s'il existe un élément <XMLPayload> avec un élément enfant <XPath> qui ne contient aucun élément <Expression>, ou si l'élément <Expression> n'est pas défini sur une valeur. Si c'est le cas, alors il s'agit de la cause de l'erreur.

    Par exemple, voici une règle de protection des expressions régulières incluant un élément <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>

    Comme un élément <Expression> est vide dans l'élément <XPath>, le déploiement du proxy d'API échoue.

Solution

Vérifiez que la règle RegularExpressionProtection possède un élément <Expression> non vide et valide défini sous l'élément <XPath>. Exemple :

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

Message d'erreur

Le déploiement du proxy d'API par le biais de l'interface utilisateur ou l'API Apigee échoue avec le message d'erreur suivant :

Error Saving Revision revision_number
RegularExpressionProtection policy_name: Empty JSONPath expression.

Exemple de message d'erreur

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

Exemple de capture d'écran d'erreur

Texte d&#39;erreur EmptyJSONPathExpression

Cause

Si la règle RegularExpressionProtection ne contient pas d'élément <Expression> défini dans l'élément <JSONPath>, le déploiement du proxy d'API échoue.

Diagnostic

  1. Identifiez la règle de protection des expressions régulières défaillante à partir du message d'erreur. Par exemple, dans l'erreur suivante, le nom de la règle est Regular-Expression-Protection-1 :

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

  2. Dans le fichier XML de la règle de protection des expressions régulières défaillante, déterminez s'il existe un élément <JSONPayload> avec un élément enfant <JSONPath> qui ne contient aucun élément <Expression>, ou si l'élément <Expression> n'est pas défini sur une valeur. Si c'est le cas, alors il s'agit de la cause de l'erreur.

    Par exemple, voici une règle de protection des expressions régulières incluant un élément <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>

    Comme un élément <Expression> est vide dans l'élément <JSONPath>, le déploiement du proxy d'API échoue.

Solution

Vérifiez que la règle RegularExpressionProtection possède un élément <Expression> non vide et valide défini sous l'élément <JSONPath>. Exemple :

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