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
Nota
Ora supportiamo principalmente il runtime APPSYNC _JS e la relativa documentazione. Valuta la possibilità di utilizzare il runtime APPSYNC _JS e le relative guide qui.
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": { ... } }
Nota
Se state cercando di accedere a una voce del dizionario/della mappa (come una voce incontext
) utilizzando la relativa chiave per recuperare il valore, Velocity Template Language () consente di utilizzare direttamente la notazione. VTL <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 "_"). Ti consigliamo di utilizzare sempre una notazione <dictionary-element>.get("<key-name>")
.
Ogni campo nella mappa $context
è definito nel modo seguente:
$context
campi
-
arguments
-
Una mappa contenente tutti gli argomenti GraphQL per questo campo.
-
identity
-
Un oggetto contenente le informazioni sul chiamante. Vedi Identità 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
.
-
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.
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.
- Autorizzazione
API_KEY
-
Il
identity
campo non è compilato. - Autorizzazione
AWS_LAMBDA
-
identity
Contiene laresolverContext
chiave, contenente lo stessoresolverContext
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
oDENY
). -
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 TCP connessione. Se la richiesta include un'x-forwarded-for
intestazione, l'IP di origine è un elenco di indirizzi IP dell'x-forwarded-for
intestazione, oltre all'indirizzo IP della connessione. TCP -
sub
-
L'UUIDutente autenticato.
-
user
-
L'IAMutente.
-
userArn
-
L'Amazon Resource Name (ARN) dell'IAMutente.
-
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 diAWS_IAM
autorizzazione, il valore del nome utente è il valore del AWS codice utente. Se utilizzi IAM l'autorizzazione con credenziali fornite dai pool di identità di Amazon Cognito, ti consigliamo di utilizzare.cognitoIdentityId
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'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
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:
-
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
-
Una rappresentazione in formato stringa del set di selezione, formattata come linguaggio SDL di definizione dello schema 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()
oncontext.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
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. } }