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

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

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": { ... }
}

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

$context campi

Identità

La sezione identity contiene le informazioni sul chiamante. La forma di questa sezione dipende dal tipo di autorizzazione del tuo. AWS AppSync API

Per ulteriori informazioni sulle opzioni di AWS AppSync sicurezza, consulta Autorizzazione e autenticazione.

Ogni campo è definito nel modo seguente:

Intestazioni delle richieste di accesso

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 API chiave 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 essere quanto segue 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'customintestazione è 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].

Accedi al nome di dominio personalizzato della richiesta

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

Info

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:

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

selectionSetListespone 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

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 mappatura rappresentanoJSON, la sanificazione degli input avviene mediante l'eliminazione dei caratteri JSON riservati dalle stringhe che rappresentano gli input dell'utente. È consigliabile utilizzare l'$util.toJson()utilità per evitare i caratteri JSON riservati dai valori sensibili delle stringhe quando li si inserisce in un modello di mappatura.

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 senza escape JSON interrompano 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, che inseriamo direttamente senza sanificazione. $context.arguments.id Questo non funziona per le stringhe che contengono virgolette senza escape o altri caratteri JSON riservati 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.
    }
}