Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

AWS AppSync Kontextreferenz für Resolver-Mapping-Vorlagen

AWS AppSync definiert eine Reihe von Variablen und Funktionen für die Arbeit mit Resolver-Mapping-Vorlagen. Dies erleichtert logische Operationen an Daten mit GraphQL. In diesem Dokument werden diese Funktionen beschrieben und Beispiele für das Arbeiten mit Vorlagen gegeben.

Zugreifen auf den $context

Die Variable $context ist eine Zuweisung, die alle Kontextinformationen für den Resolver-Aufruf enthält. Sie hat die folgende Struktur:

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

Jedes Feld in der $context-Zuordnung ist wie folgt definiert:

$context-Felder

Identität

Der Abschnitt identity enthält Informationen über den Aufrufer. Die Form dieses Abschnitts hängt von Ihrem AWS AppSync API Autorisierungstyp ab.

Weitere Informationen zu AWS AppSync Sicherheitsoptionen finden Sie unter Autorisierung und Authentifizierung.

Jedes Feld ist wie folgt definiert:

Auf die Header der Anfrage zugreifen

AWS AppSync unterstützt die Übergabe benutzerdefinierter Header von Clients und den Zugriff auf sie in Ihren GraphQL-Resolvern mithilfe von. $context.request.headers Sie können die Header-Werte dann für Aktionen wie das Einfügen von Daten in eine Datenquelle oder für Autorisierungsprüfungen verwenden. Sie können einzelne oder mehrere Anforderungsheader $curl mithilfe einer API Taste von der Befehlszeile aus verwenden, wie in den folgenden Beispielen gezeigt:

Beispiel für einen einzelnen Header

Angenommen, Sie legen wie folgt einen custom-Header mit dem Wert nadia fest:

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

Darauf könnte dann mit $context.request.headers.custom zugegriffen werden. Für DynamoDB könnte es beispielsweise wie folgt VTL sein:

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

Beispiel für mehrere Header

Sie können auch mehrere Header in einer einzigen Anforderung übergeben und auf diese in der Resolver-Zuweisungsvorlage zugreifen. Zum Beispiel, wenn der custom Header mit zwei Werten festgelegt ist:

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

Sie können dann darauf als Array zugreifen, z. B. $context.request.headers.custom[1].

Greifen Sie auf den angeforderten benutzerdefinierten Domainnamen zu

AWS AppSync unterstützt die Konfiguration einer benutzerdefinierten Domain, mit der Sie auf Ihre GraphQL- und Echtzeit-Endpunkte für Ihre zugreifen können. APIs Wenn Sie eine Anfrage mit einem benutzerdefinierten Domainnamen stellen, können Sie den Domainnamen mithilfe von abrufen. $context.request.domainName

Bei Verwendung des standardmäßigen GraphQL-Endpunktdomänennamens lautet der Wert. null

Informationen

Der Abschnitt info enthält Informationen über die GraphQL-Anforderung. Dieser Abschnitt hat die folgende Form:

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

Jedes Feld ist wie folgt definiert:

Angenommen, Sie lösen das getPost-Feld der folgenden Abfrage auf:

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

Dann könnte die vollständige $context.info-Variable, die bei der Verarbeitung einer Zuweisungsvorlage verfügbar ist, folgendermaßen aussehen:

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

selectionSetListmacht nur Felder verfügbar, die zum aktuellen Typ gehören. Wenn es sich bei dem aktuellen Typ um eine Schnittstelle oder Union handelt, werden nur ausgewählte Felder angezeigt, die zur Schnittstelle gehören. Nehmen wir zum Beispiel das folgende Schema:

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
}

Und die folgende Abfrage:

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

        ... on Blog {
            title
        }
    }
}

$ctx.info.selectionSetListBeim Aufrufen mit der Query.node Feldauflösung id wird nur angezeigt:

"selectionSetList": [
    "id"
]

Bereinigung von Eingängen

Anwendungen müssen nicht vertrauenswürdige Eingaben bereinigen, um zu verhindern, dass externe Parteien eine Anwendung anders als beabsichtigt verwenden. Da das Benutzereingaben in Eigenschaften wie$context.arguments,,, und $context enthält $context.identity $context.result$context.info.variables, muss darauf geachtet werden$context.request.headers, dass deren Werte in Mapping-Vorlagen bereinigt werden.

Da Mapping-Vorlagen das darstellenJSON, erfolgt die Bereinigung von Eingaben in der Form, dass JSON reservierte Zeichen in Zeichenketten, die Benutzereingaben darstellen, maskiert werden. Es hat sich bewährt, das $util.toJson() Hilfsprogramm zu verwenden, um JSON reservierte Zeichen aus sensiblen Zeichenkettenwerten zu maskieren, wenn sie in eine Zuordnungsvorlage eingefügt werden.

In der folgenden Lambda-Anforderungszuordnungsvorlage haben wir beispielsweise, weil wir auf eine unsichere Kundeneingabezeichenfolge ($context.arguments.id) zugegriffen haben, diese umschlossen, $util.toJson() um zu verhindern, dass Zeichen ohne JSON Escape-Zeichen die Vorlage beschädigen. JSON

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

Im Gegensatz zur unten stehenden Zuordnungsvorlage, bei der wir sie direkt einfügen$context.arguments.id, ohne sie zu bereinigen. Dies funktioniert nicht für Zeichenketten, die Anführungszeichen ohne Escape-Zeichen oder andere JSON reservierte Zeichen enthalten, und kann dazu führen, dass Ihre Vorlage fehlerhaft wird.

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