Partager via

Valider une demande GraphQL

  • Article

S’APPLIQUE À : Tous les niveaux de Gestion des API

La stratégie validate-graphql-request valide la requête GraphQL et autorise l’accès à des chemins de requête spécifiques dans une API GraphQL. Une requête non valide est une « erreur de demande ». L’autorisation n’est effectuée que pour les demandes valides.

Notes

Définissez les éléments enfants et de stratégie dans l’ordre fourni dans l’instruction de stratégie. En savoir plus sur comment définir ou modifier des stratégies du service Gestion des API.

Instruction de la stratégie

<validate-graphql-request error-variable-name="variable name" max-size="size in bytes" max-depth="query depth">
    <authorize>
        <rule path="query path, for example: '/listUsers' or '/__*'" action="string or policy expression that evaluates to 'allow | remove | reject | ignore'" />
    </authorize>
</validate-graphql-request>

Attributs

Attribut Description Obligatoire Default
error-variable-name Nom de la variable dans context.Variables dans laquelle enregistrer les erreurs de validation. Les expressions de stratégie sont autorisées. Non N/A
max-size Taille maximale de la charge utile de la demande, en octets. Valeur maximale autorisée : 102 400 octets (100 Ko). (Contactez le support technique si vous avez besoin d’augmenter cette limite.) Les expressions de stratégie sont autorisées. Oui N/A
max-depth Entier. Profondeur de requête maximale. Les expressions de stratégie sont autorisées. Non 6

Éléments

Nom Description Obligatoire
autoriser Ajoutez cet élément pour définir une règle d’autorisation appropriée pour un ou plusieurs chemins d’accès. Non
rule Ajoutez un ou plusieurs de ces éléments pour autoriser des chemins d’accès de requête spécifiques. Chaque règle peut éventuellement fournir une action différente. Peut être spécifié de manière conditionnelle à l’aide d’une expression de stratégie. Non

Attributs de rôle

Attribut Description Obligatoire Default
path Chemin d’accès pour exécuter la validation d’autorisation activé. Il doit suivre le modèle : /type/field. Oui N/A
action Action à exécuter si la règle s’applique. Peut être spécifié de manière conditionnelle à l’aide d’une expression de stratégie. Non allow

Système d’introspection

La stratégie pour path=/__* est le système d’introspection. Vous pouvez l’utiliser pour rejeter les demandes d’introspection (__schema, __type, etc.).

Actions de demande

Les actions disponibles sont décrites dans le tableau suivant.

Action Description
reject Une erreur de demande se produit et la demande n’est pas envoyée au back-end. Des règles supplémentaires si celles qui sont configurées ne sont pas appliquées.
suppression Une erreur de champ se produit et le champ est supprimé de la demande.
allow Le champ est passé au back-end.
ignore La règle n’est pas valide pour ce cas et la règle suivante est appliquée.

Usage

Notes d’utilisation

  • Configurez la stratégie pour une API GraphQL directe ou synthétique qui a été importée dans Gestion des API.

  • Cette stratégie ne peut être employée qu’une seule fois dans une section de stratégie.

  • Étant donné que les requêtes GraphQL utilisent un schéma aplati, les autorisations peuvent être appliquées à n’importe quel nœud feuille d’un type de sortie :

    • Mutation, requête ou abonnement
    • Champ individuel dans une déclaration de type

    Les autorisations ne peuvent pas être appliquées aux éléments suivants :

    • Types d’entrée
    • Fragments
    • Unions
    • Interfaces
    • Élément de schéma

  • La stratégie peut valider les requêtes GraphQL contenant jusqu’à 250 champs de requête à tous les niveaux.

Gestion des erreurs

Un échec de validation par rapport au schéma GraphQL ou un échec lié à la taille ou à la profondeur de la demande constitue une erreur de demande et entraîne son échec avec un bloc d’erreurs (mais pas de bloc de données).

Comme pour la propriété Context.LastError, toutes les erreurs de validation GraphQL sont automatiquement propagées dans la variable GraphQLErrors. Si les erreurs doivent être propagées séparément, vous pouvez spécifier un nom de variable d’erreur. Les erreurs font l’objet d’un push sur la variable error et la variable GraphQLErrors.

Exemples

Validation de requête

Cet exemple applique les règles de validation et d’autorisation suivantes à une requête GraphQL :

  • Demandes supérieures à 100 Ko ou avec une profondeur de requête supérieure à 4.
  • Les demandes adressées au système d’introspection sont rejetées.
  • Le champ /Missions/name est supprimé des requêtes contenant plus de deux en-têtes.
<validate-graphql-request error-variable-name="name" max-size="102400" max-depth="4"> 
    <authorize>
        <rule path="/__*" action="reject" /> 
        <rule path="/Missions/name" action="@(context.Request.Headers.Count > 2 ? "remove" : "allow")" />
    </authorize>
</validate-graphql-request>

Validation de mutation

Cet exemple applique les règles de validation et d’autorisation suivantes à une mutation GraphQL :

  • Demandes supérieures à 100 Ko ou avec une profondeur de requête supérieure à 4.
  • Les demandes de mutation du champ deleteUser sont refusées, sauf lorsque la demande provient de l’adresse IP 198.51.100.1.
<validate-graphql-request error-variable-name="name" max-size="102400" max-depth="4"> 
    <authorize>
        <rule path="/Mutation/deleteUser" action="@(context.Request.IpAddress <> "198.51.100.1" ? "deny" : "allow")" />
    </authorize>
</validate-graphql-request>

Contenu connexe

Pour plus d’informations sur l’utilisation des stratégies, consultez :