

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# AWS AppSync riferimento al contesto del modello di mappatura del resolver
<a name="resolver-context-reference"></a>

**Nota**  
Ora supportiamo principalmente il runtime APPSYNC\$1JS e la relativa documentazione. [Prendi in considerazione l'utilizzo del runtime APPSYNC\$1JS e delle relative guide qui.](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-reference-js-version.html)

AWS AppSync definisce un insieme di variabili e funzioni per lavorare con i modelli di mappatura dei resolver. Ciò semplifica le operazioni logiche sui dati con GraphQL. Questo documento descrive queste funzioni e offre alcuni esempi per l'uso dei modelli.

## Accesso a `$context`
<a name="accessing-the-context"></a>

La variabile `$context` è una mappa contenente tutte le informazioni contestuali per la chiamata del resolver. Ha la struttura seguente:

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

**Nota**  
Se state cercando di accedere a una dictionary/map voce (ad esempio una voce in`context`) utilizzando la relativa chiave per recuperare il valore, il Velocity Template Language (VTL) consente di utilizzare direttamente la notazione. `<dictionary-element>.<key-name>` Tuttavia, questo potrebbe non funzionare per tutti i casi, ad esempio quando i nomi di chiavi dispongono di caratteri speciali (per esempio, un segno di sottolineatura "\$1"). Ti consigliamo di utilizzare sempre una notazione `<dictionary-element>.get("<key-name>")`.

Ogni campo nella mappa `$context` è definito nel modo seguente:

### `$context` campi
<a name="accessing-the-context-list"></a>

** `arguments` **  
Una mappa contenente tutti gli argomenti GraphQL per questo campo.

** `identity` **  
Un oggetto contenente le informazioni sul chiamante. Vedi [Identità](#aws-appsync-resolver-context-reference-identity) per ulteriori informazioni sulla struttura di questo campo.

** `source` **  
Una mappa contenente la risoluzione del campo padre.

** `stash` **  
Lo stash è una mappa disponibile all'interno di ogni modello di mappatura di funzione o resolver. La sua istanza viene attivata dall'esecuzione del resolver. Ciò significa che è possibile trasferire arbitrariamente i dati tra i modelli di mappatura della richiesta e della risposta e tra le funzioni di un resolver di pipeline. Lo stash ammette gli stessi metodi previsti dalla struttura di dati di una [mappa Java](https://docs.oracle.com/javase/8/docs/api/java/util/Map.html).

** `result` **  
Un container per i risultati di questo resolver. Questo campo è disponibile solo per i modelli di mappatura delle risposte.  
Ad esempio, se stai risolvendo il `author` campo della seguente query:  

```
query {
    getPost(id: 1234) {
        postId
        title
        content
        author {
            id
            name
        }
    }
}
```
La variabile `$context` completa disponibile durante l'elaborazione di un modello di mappatura della risposta potrebbe essere:  

```
{
  "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` **  
Il risultato di qualsiasi operazione precedente sia stata eseguita in un resolver di pipeline.  
Se l'operazione precedente era il modello Before mapping del risolutore di pipeline, allora `$ctx.prev.result` rappresenta l'output della valutazione del modello e viene reso disponibile per la prima funzione nella pipeline.  
Se l'operazione precedente corrisponde alla prima funzione, `$ctx.prev.result` è l'output della prima funzione, disponibile per la seconda funzione della pipeline.  
Se l'operazione precedente era l'ultima funzione, `$ctx.prev.result` rappresenta l'output dell'ultima funzione e viene resa disponibile al modello After mapping del risolutore di pipeline.

** `info` **  
Un oggetto contenente le informazioni sulla richiesta GraphQL. Per la struttura di questo campo, consulta [Info](#aws-appsync-resolver-context-reference-info).

### Identità
<a name="aws-appsync-resolver-context-reference-identity"></a>

La sezione `identity` contiene le informazioni sul chiamante. La forma di questa sezione dipende dal tipo di autorizzazione dell'API. AWS AppSync 

Per ulteriori informazioni sulle opzioni di AWS AppSync sicurezza, consulta [Autorizzazione e autenticazione](security-authz.md#aws-appsync-security).

** Autorizzazione `API_KEY`**  
Il `identity` campo non è compilato.

**Autorizzazione `AWS_LAMBDA`**  
`identity`Contiene la `resolverContext` chiave, contenente lo stesso `resolverContext` contenuto restituito dalla funzione Lambda che autorizza la richiesta.

** Autorizzazione `AWS_IAM`**  
`identity`Ha la seguente forma:  

```
{
    "accountId" : "string",
    "cognitoIdentityPoolId" : "string",
    "cognitoIdentityId" : "string",
    "sourceIp" : ["string"],
    "username" : "string", // IAM user principal
    "userArn" : "string",
    "cognitoIdentityAuthType" : "string", // authenticated/unauthenticated based on the identity type
    "cognitoIdentityAuthProvider" : "string" // the auth provider that was used to obtain the credentials
}
```

** Autorizzazione `AMAZON_COGNITO_USER_POOLS`**  
`identity`Ha la forma seguente:  

```
{
    "sub" : "uuid",
    "issuer" : "string",
    "username" : "string"
    "claims" : { ... },
    "sourceIp" : ["x.x.x.x"],
    "defaultAuthStrategy" : "string"
}
```

Ogni campo è definito nel modo seguente:

** `accountId` **  
L'ID dell' AWS account del chiamante.

** `claims` **  
Le attestazioni dell'utente.

** `cognitoIdentityAuthType` **  
Autenticato o non autenticato in base al tipo di identità.

** `cognitoIdentityAuthProvider` **  
Un elenco separato da virgole di informazioni sul provider di identità esterno utilizzato per ottenere le credenziali utilizzate per firmare la richiesta.

** `cognitoIdentityId` **  
L'ID identificativo Amazon Cognito del chiamante.

** `cognitoIdentityPoolId` **  
L'ID del pool di identità di Amazon Cognito associato al chiamante.

** `defaultAuthStrategy` **  
La strategia di autorizzazione predefinita per questo chiamante (`ALLOW` o `DENY`).

** `issuer` **  
L'emittente del token.

** `sourceIp` **  
L'indirizzo IP di origine del chiamante che riceve. AWS AppSync Se la richiesta non include l'`x-forwarded-for`intestazione, il valore IP di origine contiene solo un singolo indirizzo IP della connessione TCP. Se la richiesta include un'intestazione `x-forwarded-for`, l'IP di origine sarà un elenco di indirizzi IP dell'intestazione `x-forwarded-for` oltre all'indirizzo IP proveniente dalla connessione TCP.

** `sub` **  
l'UUID dell'utente autenticato.

** `user` **  
L'utente IAM.

** `userArn` **  
L'Amazon Resource Name (ARN) dell'utente IAM.

** `username` **  
Il nome dell'utente autenticato. In caso di autorizzazione `AMAZON_COGNITO_USER_POOLS`, il valore del *nome utente* è il valore dell'attributo *cognito:username*. In caso di `AWS_IAM` autorizzazione, il valore del *nome utente* è il valore del principale AWS utente. Se utilizzi l'autorizzazione IAM con credenziali fornite dai pool di identità di Amazon Cognito, ti consigliamo di utilizzare. `cognitoIdentityId`

### Intestazioni delle richieste di accesso
<a name="aws-appsync-resolver-context-reference-util"></a>

AWS AppSync supporta il passaggio di intestazioni personalizzate dai client e l'accesso ad esse nei resolver GraphQL utilizzando. `$context.request.headers` È quindi possibile utilizzare i valori dell'intestazione per azioni come l'inserimento di dati in una fonte di dati o i controlli di autorizzazione. È possibile utilizzare intestazioni di richiesta singole o multiple utilizzando `$curl` una chiave API dalla riga di comando, come illustrato negli esempi seguenti:

**Esempio di intestazione singola** 

Supponi di impostare un'intestazione `custom` con il valore `nadia` come segue:

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

Potrai quindi accedervi con `$context.request.headers.custom`. Ad esempio, potrebbe trovarsi nel seguente VTL per DynamoDB:

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

**Esempio di intestazione multipla** 

Puoi anche passare intestazioni multiple in una singola richiesta e accedervi nel modello di mappatura del resolver. Ad esempio, se l'`custom`intestazione è impostata con due valori:

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

Potrai quindi accedervi come matrice, ad esempio `$context.request.headers.custom[1]`.

**Nota**  
AWS AppSync non espone l'intestazione del cookie in. `$context.request.headers`

### Accedi al nome di dominio personalizzato della richiesta
<a name="aws-access-requested-custom-domain-names"></a>

AWS AppSync supporta la configurazione di un dominio personalizzato che puoi utilizzare per accedere ai tuoi endpoint GraphQL e in tempo reale per il tuo. APIs Quando si effettua una richiesta con un nome di dominio personalizzato, è possibile ottenere il nome di dominio utilizzando. `$context.request.domainName`

Quando si utilizza il nome di dominio endpoint GraphQL predefinito, il valore è. `null`

### Informazioni
<a name="aws-appsync-resolver-context-reference-info"></a>

La sezione `info` contiene informazioni sulla richiesta GraphQL. Questa sezione ha il seguente formato:

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

Ogni campo è definito nel modo seguente:

** `fieldName` **  
Il nome del campo attualmente in corso di risoluzione.

** `parentTypeName` **  
Il nome del tipo padre per il campo attualmente in corso di risoluzione.

** `variables` **  
Una mappa contenente tutte le variabili che vengono passate nella richiesta GraphQL.

** `selectionSetList` **  
Rappresentazione elenco dei campi nel set di selezione GraphQL. I campi con alias sono referenziati solo dal nome dell'alias, non dal nome del campo. L'esempio seguente mostra questa indicazione in dettaglio.

** `selectionSetGraphQL` **  
Rappresentazione stringa del set di selezione, formattata come SDL (Schema Definition Language) GraphQL. Sebbene i frammenti non vengano uniti nel set di selezione, i frammenti in linea vengono conservati, come illustrato nell'esempio seguente.

**Nota**  
Quando si utilizza `$utils.toJson()` on`context.info`, i valori che `selectionSetGraphQL` e `selectionSetList` restituiscono non vengono serializzati per impostazione predefinita.

Ad esempio, se stai risolvendo il campo `getPost` della query seguente:

```
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 variabile `$context.info` completa disponibile durante l'elaborazione di un modello di mappatura potrebbe essere:

```
{
  "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`espone solo i campi che appartengono al tipo corrente. Se il tipo corrente è un'interfaccia o un'unione, vengono esposti solo i campi selezionati che appartengono all'interfaccia. Ad esempio, dato lo schema seguente:

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

E la seguente domanda:

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

        ... on Blog {
            title
        }
    }
}
```

Quando si chiama `$ctx.info.selectionSetList` alla risoluzione del `Query.node` campo, `id` viene esposto solo:

```
"selectionSetList": [
    "id"
]
```

## Neutralizzazione degli input
<a name="sanitizing-inputs"></a>

Le applicazioni devono neutralizzare gli input non attendibili per impedire a qualsiasi parte esterna di utilizzare un'applicazione al di fuori dell'uso previsto. Poiché `$context` contiene gli input degli utenti in proprietà come`$context.arguments`,,, e`$context.request.headers`,,`$context.identity`,`$context.result`,`$context.info.variables`, è necessario prestare attenzione a ripulirne i valori nei modelli di mappatura.

Poiché i modelli di mapping sono rappresentati in JSON, la neutralizzazione degli input assume la forma di caratteri riservati JSON di escape delle stringhe che rappresentano gli input dell'utente. È consigliabile utilizzare l'utilità `$util.toJson()` per applicare i caratteri riservati JSON di escape di valori di stringa sensibili quando vengono inseriti in un modello di mapping.

Ad esempio, nel seguente modello di mappatura delle richieste Lambda, poiché abbiamo avuto accesso a una stringa di input del cliente non sicura (`$context.arguments.id`), l'abbiamo inserita `$util.toJson()` per evitare che i caratteri JSON senza escape violassero il modello JSON.

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

A differenza del modello di mappatura riportato di seguito, in cui inseriamo direttamente senza sanificazione. `$context.arguments.id` Questo non funziona per le stringhe che contengono virgolette senza scampo o altri caratteri riservati JSON e può lasciare il modello esposto a errori.

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