

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 JavaScript référence à l'objet contextuel du résolveur
<a name="resolver-context-reference-js"></a>

AWS AppSync définit un ensemble de variables et de fonctions permettant de travailler avec les gestionnaires de demandes et de réponses. Cela facilite les opérations logiques sur les données avec GraphQL. Ce document décrit ces fonctions et fournit des exemples.

## Accès à la variable `context`
<a name="accessing-the-context-js"></a>

L'`context`argument d'un gestionnaire de demandes et de réponses est un objet qui contient toutes les informations contextuelles pour l'invocation de votre résolveur. Elle présente la structure suivante :

```
type Context = {
  arguments: any;
  args: any;
  identity: Identity;
  source: any;
  error?: {
    message: string;
    type: string;
  };
  stash: any;
  result: any;
  prev: any;
  request: Request;
  info: Info;
};
```

**Note**  
Vous constaterez souvent que l'`context`objet est appelé`ctx`.

Chaque champ de l'`context`objet est défini comme suit :

### Champs de `context`
<a name="accessing-the-context-list-js"></a>

** `arguments` **  
Carte qui contient tous les arguments GraphQL pour ce champ.

** `identity` **  
Objet qui contient des informations sur l’appelant. Pour en savoir plus sur la structure de ce champ, consultez [Identité](#aws-appsync-resolver-context-reference-identity-js).

** `source` **  
Carte contenant la résolution du champ parent.

** `stash` **  
Le stash est un objet mis à disposition dans chaque résolveur et gestionnaire de fonctions. Le même objet de réserve vit après une seule exécution du résolveur. Cela signifie que vous pouvez utiliser le stash pour transmettre des données arbitraires entre les gestionnaires de requêtes et de réponses et entre les fonctions d'un résolveur de pipeline.   
Vous ne pouvez pas supprimer ou remplacer l'intégralité de la réserve, mais vous pouvez ajouter, mettre à jour, supprimer et lire les propriétés de la réserve. 
Vous pouvez ajouter des objets à la réserve en modifiant l'un des exemples de code ci-dessous :  

```
//Example 1
ctx.stash.newItem = { key: "something" }

//Example 2
Object.assign(ctx.stash, {key1: value1, key2: value})
```
Vous pouvez supprimer des objets de la réserve en modifiant le code ci-dessous :  

```
delete ctx.stash.key
```

** `result` **  
Un conteneur pour les résultats de ce résolveur. Ce champ n'est disponible que pour les gestionnaires de réponses.  
Par exemple, si vous résolvez le `author` champ de la requête suivante :  

```
query {
    getPost(id: 1234) {
        postId
        title
        content
        author {
            id
            name
        }
    }
}
```
La `context` variable complète est alors disponible lorsqu'un gestionnaire de réponses est évalué :  

```
{
  "arguments" : {
    id: "1234"
  },
  "source": {},
  "result" : {
      "postId": "1234",
      "title": "Some title",
      "content": "Some content",
      "author": {
        "id": "5678",
        "name": "Author Name"
      }
  },
  "identity" : {
      "sourceIp" : ["x.x.x.x"],
      "userArn" : "arn:aws:iam::123456789012:user/appsync",
      "accountId" : "666666666666",
      "user" : "AIDAAAAAAAAAAAAAAAAAA"
  }
}
```

** `prev.result` **  
Le résultat de toute opération précédente exécutée dans un résolveur de pipeline.  
Si l'opération précédente était le gestionnaire de requêtes du résolveur de pipeline, elle `ctx.prev.result` représente le résultat de l'évaluation et est mise à la disposition de la première fonction du pipeline.  
Si l'opération précédente était la première fonction, elle `ctx.prev.result` représente le résultat de l'évaluation du gestionnaire de réponse de la première fonction et est mise à la disposition de la deuxième fonction du pipeline.  
Si l'opération précédente était la dernière fonction, elle `ctx.prev.result` représente le résultat de l'évaluation de la dernière fonction et est mise à la disposition du gestionnaire de réponses du résolveur de pipeline.

** `info` **  
Objet qui contient des informations sur la demande GraphQL. Pour obtenir la structure de ce champ, veuillez consulter [Infos](#aws-appsync-resolver-context-reference-info-js).

### Identity
<a name="aws-appsync-resolver-context-reference-identity-js"></a>

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](security-authz.md#aws-appsync-security).

** Autorisation `API_KEY`**  
Le `identity` champ n'est pas renseigné.

**Autorisation `AWS_LAMBDA`**  
`identity`Il a la forme suivante :  

```
type AppSyncIdentityLambda = {
  resolverContext: any;
};
```
`identity`Il contient la `resolverContext` clé, contenant le même `resolverContext` contenu renvoyé par la fonction Lambda autorisant la demande.

** Autorisation `AWS_IAM`**  
`identity`Il a la forme suivante :  

```
type AppSyncIdentityIAM = {
  accountId: string;
  cognitoIdentityPoolId: string;
  cognitoIdentityId: string;
  sourceIp: string[];
  username: string;
  userArn: string;
  cognitoIdentityAuthType: string;
  cognitoIdentityAuthProvider: string;
};
```

** Autorisation `AMAZON_COGNITO_USER_POOLS`**  
`identity`Il a la forme suivante :  

```
type AppSyncIdentityCognito = {
  sourceIp: string[];
  username: string;
  groups: string[] | null;
  sub: string;
  issuer: string;
  claims: any;
  defaultAuthStrategy: string;
};
```

Chaque champ est défini comme suit :

** `accountId` **  
L'identifiant du AWS compte de l'appelant.

** `claims` **  
Demandes de l'utilisateur.

** `cognitoIdentityAuthType` **  
Authentifié ou non authentifié en fonction du type d'identité.

** `cognitoIdentityAuthProvider` **  
Liste séparée par des virgules des informations du fournisseur d'identité externe utilisées pour obtenir les informations d'identification utilisées pour signer la demande.

** `cognitoIdentityId` **  
L'identifiant Amazon Cognito de l'appelant.

** `cognitoIdentityPoolId` **  
L'ID du pool d'identités Amazon Cognito associé à l'appelant.

** `defaultAuthStrategy` **  
Stratégie d'autorisation par défaut pour cet appelant (`ALLOW` ou `DENY`).

** `issuer` **  
Émetteur du jeton.

** `sourceIp` **  
Adresse IP source de l'appelant qui AWS AppSync reçoit. Si la demande n'inclut pas l'`x-forwarded-for`en-tête, la valeur IP source ne contient qu'une seule adresse IP provenant de la connexion TCP. Si la demande inclut un en-tête `x-forwarded-for`, l'adresse IP source est une liste d'adresses IP de l'en-tête `x-forwarded-for` en plus de l'adresse IP de la connexion TCP.

** `sub` **  
UUID de l'utilisateur authentifié.

** `user` **  
Utilisateur IAM.

** `userArn` **  
Le nom de ressource Amazon (ARN) de l'utilisateur IAM.

** `username` **  
Nom de l'utilisateur authentifié. En cas d'autorisation `AMAZON_COGNITO_USER_POOLS`, la valeur de *username* est la valeur de l’attribut *cognito:username*. Dans le cas d'`AWS_IAM`une autorisation, la valeur du *nom d'utilisateur* est la valeur de l' AWS utilisateur principal. Si vous utilisez l'autorisation IAM avec des informations d'identification provenant de pools d'identités Amazon Cognito, nous vous recommandons d'utiliser. `cognitoIdentityId`

### En-têtes de demande d'accès
<a name="aws-appsync-resolver-context-reference-util-js"></a>

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. `ctx.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'`$curl`aide d'une clé d'API 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 `ctx.request.headers.custom`. Par exemple, cela peut se trouver dans le code suivant pour DynamoDB :

```
"custom": util.dynamodb.toDynamoDB(ctx.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 gestionnaire de résolution. Par exemple, si l'`custom`en-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, `ctx.request.headers.custom[1]`.

**Note**  
AWS AppSync n'expose pas l'en-tête du cookie dans`ctx.request.headers`.

### Accédez au nom de domaine personnalisé de la demande
<a name="aws-access-requested-custom-domain-names-js"></a>

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

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

### Info (Infos)
<a name="aws-appsync-resolver-context-reference-info-js"></a>

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

```
type Info = {
  fieldName: string;
  parentTypeName: string;
  variables: any;
  selectionSetList: string[];
  selectionSetGraphQL: string;
};
```

Chaque champ est défini comme suit :

** `fieldName` **  
Nom du champ en cours de résolution.

** `parentTypeName` **  
Nom du type parent du champ en cours de résolution.

** `variables` **  
Carte qui contient toutes les variables transmises dans la demande GraphQL.

** `selectionSetList` **  
Représentation sous forme de liste des champs du jeu de sélection GraphQL. Les champs dotés d'un alias sont référencés uniquement par le nom de l'alias, et non par le nom du champ. L'exemple suivant détaille cela.

** `selectionSetGraphQL` **  
Représentation sous forme de chaîne du jeu de sélection, formatée en langage SDL GraphQL. Bien que les fragments ne soient pas fusionnés dans le jeu de sélection, les fragments intégrés sont conservés, comme le montre l'exemple suivant.

**Note**  
`JSON.stringify`n'inclura pas `selectionSetGraphQL` et `selectionSetList` dans la sérialisation des chaînes. Vous devez référencer ces propriétés directement.

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
  }
}
```

La `ctx.info` variable complète disponible lors du traitement d'un gestionnaire peut alors ê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}"
}
```

`selectionSetList`n'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"
]
```