Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

AWS AppSync référence contextuelle du modèle de mappage du résolveur

AWS AppSync définit un ensemble de variables et de fonctions permettant de travailler avec des modèles de mappage de résolveurs. Cela facilite les opérations logiques sur les données avec GraphQL. Le présent document décrit ces fonctions et fournit des exemples d'utilisation des modèles.

Accès à la variable $context

La variable $context est un mappage qui contient toutes les informations contextuelles pour l'appel de votre résolveur. Elle présente la structure suivante :

{
   "arguments" : { ... },
   "source" : { ... },
   "result" : { ... },
   "identity" : { ... },
   "request" : { ... },
   "info": { ... }
}

Chaque champ dans le mappage $context est défini comme suit :

Champs de $context

Identity

La section identity contient les informations sur l'appelant. La forme de cette section dépend du type d'autorisation de votre AWS AppSync API.

Pour plus d'informations sur les options AWS AppSync de sécurité, consultez la section Autorisation et authentification.

Chaque champ est défini comme suit :

En-têtes de demande d'accès

AWS AppSync permet de transmettre des en-têtes personnalisés depuis les clients et d'y accéder dans vos résolveurs GraphQL en utilisant. $context.request.headers Vous pouvez ensuite utiliser les valeurs d'en-tête pour des actions telles que l'insertion de données dans une source de données ou les contrôles d'autorisation. Vous pouvez utiliser un ou plusieurs en-têtes de demande à l'$curlaide d'une API touche depuis la ligne de commande, comme indiqué dans les exemples suivants :

Exemple d'en-tête unique

Supposons que vous définissiez un en-tête custom avec la valeur nadia, comme suit :

curl -XPOST -H "Content-Type:application/graphql" -H "custom:nadia" -H "x-api-key:<API-KEY-VALUE>" -d '{"query":"mutation { createEvent(name: \"demo\", when: \"Next Friday!\", where: \"Here!\") {id name when where description}}"}' https://<ENDPOINT>/graphql

Il est alors possible d'y accéder avec $context.request.headers.custom. Par exemple, cela peut se trouver dans ce qui suit VTL pour DynamoDB :

"custom": $util.dynamodb.toDynamoDBJson($context.request.headers.custom)

Exemple d'en-tête multiple

Vous pouvez également transmettre plusieurs en-têtes dans une seule demande et y accéder dans le modèle de mappage des résolveurs. Par exemple, si l'customen-tête est défini avec deux valeurs :

curl -XPOST -H "Content-Type:application/graphql" -H "custom:bailey" -H "custom:nadia" -H "x-api-key:<API-KEY-VALUE>" -d '{"query":"mutation { createEvent(name: \"demo\", when: \"Next Friday!\", where: \"Here!\") {id name when where description}}"}' https://<ENDPOINT>/graphql

Vous pouvez ensuite y accéder comme s'il s'agissait d'un tableau : par exemple, $context.request.headers.custom[1].

Accédez au nom de domaine personnalisé de la demande

AWS AppSync prend en charge la configuration d'un domaine personnalisé que vous pouvez utiliser pour accéder à votre GraphQL et aux points de terminaison en temps réel de votre. APIs Lorsque vous faites une demande avec un nom de domaine personnalisé, vous pouvez obtenir le nom de domaine en utilisant$context.request.domainName.

Lorsque vous utilisez le nom de domaine du point de terminaison GraphQL par défaut, la valeur est. null

Infos

La section info contient des informations sur la demande GraphQL. Cette section se présente sous la forme suivante :

{
    "fieldName": "string",
    "parentTypeName": "string",
    "variables": { ... },
    "selectionSetList": ["string"],
    "selectionSetGraphQL": "string"
}

Chaque champ est défini comme suit :

Par exemple, si vous résolvez le champ getPost de la requête suivante :

query {
  getPost(id: $postId) {
    postId
    title
    secondTitle: title
    content
    author(id: $authorId) {
      authorId
      name
    }
    secondAuthor(id: "789") {
      authorId
    }
    ... on Post {
      inlineFrag: comments: {
        id
      }
    }
    ... postFrag
  }
}

fragment postFrag on Post {
  postFrag: comments: {
    id
  }
}

Ensuite, la variable $context.info complète, disponible lors du traitement d'un modèle de mappage, peut être :

{
  "fieldName": "getPost",
  "parentTypeName": "Query",
  "variables": {
    "postId": "123",
    "authorId": "456"
  },
  "selectionSetList": [
    "postId",
    "title",
    "secondTitle"
    "content",
    "author",
    "author/authorId",
    "author/name",
    "secondAuthor",
    "secondAuthor/authorId",
    "inlineFragComments",
    "inlineFragComments/id",
    "postFragComments",
    "postFragComments/id"
  ],
  "selectionSetGraphQL": "{\n  getPost(id: $postId) {\n    postId\n    title\n    secondTitle: title\n    content\n    author(id: $authorId) {\n      authorId\n      name\n    }\n    secondAuthor(id: \"789\") {\n      authorId\n    }\n    ... on Post {\n      inlineFrag: comments {\n        id\n      }\n    }\n    ... postFrag\n  }\n}"
}

selectionSetListn'expose que les champs appartenant au type actuel. Si le type actuel est une interface ou une union, seuls les champs sélectionnés appartenant à l'interface sont exposés. Par exemple, selon le schéma suivant :

type Query {
    node(id: ID!): Node
}

interface Node {
    id: ID
}

type Post implements Node {
    id: ID
    title: String
    author: String
}

type Blog implements Node {
    id: ID
    title: String
    category: String
}

Et la requête suivante :

query {
    node(id: "post1") {
        id
        ... on Post {
            title
        }

        ... on Blog {
            title
        }
    }
}

Lors de l'appel $ctx.info.selectionSetList à la résolution du Query.node champ, seul id est exposé :

"selectionSetList": [
    "id"
]

Assainissement des entrées

Les applications doivent assainir les entrées non approuvées pour empêcher toute utilisation non prévue de ces applications par une tierce partie. Comme il $context contient des entrées utilisateur dans des propriétés telles que$context.arguments,$context.identity,$context.result,$context.info.variables, et$context.request.headers, il faut veiller à nettoyer leurs valeurs dans les modèles de mappage.

Comme les modèles de mappage le représententJSON, le nettoyage des entrées consiste à éliminer les caractères JSON réservés des chaînes représentant les entrées utilisateur. Il est recommandé d'utiliser cet $util.toJson() utilitaire pour exclure les caractères JSON réservés des valeurs de chaîne sensibles lorsque vous les placez dans un modèle de mappage.

Par exemple, dans le modèle de mappage de requêtes Lambda suivant, parce que nous avons accédé à une chaîne de saisie client non sécurisée ($context.arguments.id), nous l'avons encapsulée $util.toJson() pour empêcher les JSON caractères non échappés de casser le modèle. JSON

{
    "version": "2017-02-28",
    "operation": "Invoke",
    "payload": {
        "field": "getPost",
        "postId": $util.toJson($context.arguments.id)
    }
}

Contrairement au modèle de mappage ci-dessous, où nous insérons directement $context.arguments.id sans désinfection. Cela ne fonctionne pas pour les chaînes contenant des guillemets non échappés ou d'autres caractères JSON réservés, et votre modèle peut échouer.

## DO NOT DO THIS
{
    "version": "2017-02-28",
    "operation": "Invoke",
    "payload": {
        "field": "getPost",
        "postId": "$context.arguments.id" ## Unsafe! Do not insert $context string values without escaping JSON characters.
    }
}