Valider une demande GraphQL
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
- Sections de la stratégie : inbound
- Étendues de la stratégie : global, espace de travail, produit, API
- Passerelles : classiques, v2, consommation, auto-hébergées, espace de travail
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
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 IP198.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>
Stratégies connexes
Contenu connexe
Pour plus d’informations sur l’utilisation des stratégies, consultez :
- Tutoriel : Transformer et protéger votre API
- Référence de stratégie pour obtenir la liste complète des instructions et des paramètres de stratégie
- Expressions de stratégie
- Définir ou modifier des stratégies
- Réutilisation de configurations de stratégie
- Référentiel d’extrait de stratégie
- Créer des stratégies à l’aide de Microsoft Copilot dans Azure