As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Configurando autorização e autenticação para proteger seu GraphQL APIs

AWS AppSync oferece os seguintes tipos de autorização para proteger o GraphQL APIs: chaves de API, Lambda, IAM, OpenID Connect e grupos de usuários do Cognito. Cada opção fornece um método diferente de segurança:

Tipos de autorização

Há cinco maneiras de autorizar aplicativos a interagir com sua API AWS AppSync GraphQL. Você especifica qual tipo de autorização você usa especificando um dos seguintes valores de tipo de autorização em sua chamada de AWS AppSync API ou CLI:

Esses tipos de autorização básicos funcionam para a maioria dos desenvolvedores. Para casos de uso mais avançados, é possível adicionar modos de autorização adicionais por meio do console, da CLI e do AWS CloudFormation. Para modos de autorização adicionais, AWS AppSync fornece um tipo de autorização que usa os valores listados acima (ou sejaAPI_KEY,AWS_LAMBDA,AWS_IAM,OPENID_CONNECT, eAMAZON_COGNITO_USER_POOLS).

Ao especificar API_KEY, AWS_LAMBDA ou AWS_IAM como o tipo de autorização principal ou padrão, não é possível especificá-los novamente como um dos modos de autorização adicionais. Da mesma forma, você não pode duplicar API_KEY, AWS_LAMBDA ou AWS_IAM nos modos de autorização adicionais. É possível usar vários grupos de usuários do Amazon Cognito e provedores do OpenID Connect. No entanto, você não pode usar grupos de usuários do Amazon Cognito nem provedores do OpenID Connect duplicados entre o modo de autorização padrão e qualquer um dos outros modos de autorização. É possível especificar clientes diferentes para o grupo de usuários do Amazon Cognito ou o provedor do OpenID Connect usando a expressão regular de configuração correspondente.

API_KEY autorização

Os não autenticados APIs exigem uma limitação mais rígida do que os autenticados. APIs Uma maneira de verificar o controle de utilização para endpoints GraphQL não autenticados é por meio do uso de chaves da API. Uma chave da API é um valor codificado no aplicativo que é gerado pelo serviço AWS AppSync ao criar um endpoint GraphQL não autenticado. Você pode rotacionar as chaves de API no console, da CLI ou da Referência da API do AWS AppSync.

Console

1. Faça login no AWS Management Console e abra o AppSync console.

   1. No APIs painel, escolha sua API GraphQL.

   2. Na barra lateral, escolha Configurações.

2. Em Modo de autorização padrão, escolha Chave de API.

3. Na tabela chaves de API, escolha Adicionar chave de API.

   Uma nova chave de API será gerada na tabela.

   1. Para excluir uma chave de API antiga, selecione a chave de API na tabela e escolha Excluir.

4. Escolha Salvar na parte inferior da página.

CLI

1. Se você ainda não tiver feito isso, configure seu acesso à AWS CLI. Para obter mais informações, consulte Noções básicas de configuração.

2. Crie um objeto da API GraphQL executando o comando update-graphql-api.

   Você precisará digitar dois parâmetros para esse comando específico:

   1. O api-id da sua API GraphQL.

   2. O novo name da sua API. Você pode usar o mesmo name.

   3. O authentication-type, que será API_KEY.

   nota

   Existem outros parâmetros, como Region, que devem ser configurados, mas geralmente usam como padrão os valores de configuração da CLI.

   Veja um exemplo de comando:

   aws appsync update-graphql-api --api-id abcdefghijklmnopqrstuvwxyz --name TestAPI --authentication-type API_KEY

   Uma saída será retornada na CLI. Aqui está um exemplo em JSON:

   {
       "graphqlApi": {
           "xrayEnabled": false,
           "name": "TestAPI",
           "authenticationType": "API_KEY",
           "tags": {},
           "apiId": "abcdefghijklmnopqrstuvwxyz",
           "uris": {
               "GRAPHQL": "https://s8i3kk3ufhe9034ujnv73r513e.appsync-api.us-west-2.amazonaws.com/graphql",
               "REALTIME": "wss://s8i3kk3ufhe9034ujnv73r513e.appsync-realtime-api.us-west-2.amazonaws.com/graphql"
           },
           "arn": "arn:aws:appsync:us-west-2:348581070237:apis/abcdefghijklmnopqrstuvwxyz"
       }
   }

As chaves da API são configuráveis para até 365 dias e é possível estender uma data de expiração existente para mais 365 dias a partir dessa data. As chaves da API são recomendadas para fins de desenvolvimento ou casos de uso em que é seguro expor uma API pública.

No cliente, a chave da API é especificada pelo cabeçalho x-api-key.

Por exemplo, se o API_KEY for 'ABC123', envie uma consulta do GraphQL via curl da seguinte forma:

$ curl -XPOST -H "Content-Type:application/graphql" -H "x-api-key:ABC123" -d '{ "query": "query { movies { id } }" }' https://YOURAPPSYNCENDPOINT/graphql

AWS_LAMBDA autorização

Você pode implementar sua própria lógica de autorização de API usando uma AWS Lambda função. Você pode usar uma função do Lambda para seu autorizador primário ou secundário, mas pode haver somente uma função de autorização do Lambda por API. Ao usar funções do Lambda para autorização, o seguinte se aplica:

Por exemplo, se o token de autorização for 'ABC123', envie uma consulta do GraphQL via curl da seguinte forma:

$ curl -XPOST -H "Content-Type:application/graphql" -H "Authorization:ABC123" -d '{ "query":
         "query { movies { id } }" }' https://YOURAPPSYNCENDPOINT/graphql
      

As funções do Lambda são chamadas antes de cada consulta ou mutação. O valor de retorno pode ser armazenado em cache com base no ID da API e no token de autenticação. Por padrão, o armazenamento em cache não está habilitado, mas isso pode ser habilitado no nível da API ou definindo o valor ttlOverride no valor de retorno de uma função.

Uma expressão regular que valida os tokens de autorização antes que a função seja chamada pode ser especificada, se desejado. Essas expressões regulares são usadas para validar se um token de autorização está no formato correto antes de sua função ser chamada. Qualquer solicitação que use um token que não corresponda a essa expressão regular será negada automaticamente.

As funções Lambda usadas para autorização exigem que uma política principal seja aplicada appsync.amazonaws.com a elas AWS AppSync para permitir sua chamada. Essa ação é feita automaticamente no AWS AppSync console; o AWS AppSync console não remove a política. Para obter mais informações sobre como anexar políticas às funções do Lambda, consulte Políticas baseadas em recursos no Guia do desenvolvedor. AWS Lambda

A função do Lambda que você especificar receberá um evento com a seguinte forma:

{
    "authorizationToken": "ExampleAUTHtoken123123123",
    "requestContext": {
        "apiId": "aaaaaa123123123example123",
        "accountId": "111122223333",
        "requestId": "f4081827-1111-4444-5555-5cf4695f339f",
        "queryString": "mutation CreateEvent {...}\n\nquery MyQuery {...}\n",
        "operationName": "MyQuery",
        "variables": {}
    }
    "requestHeaders": {
        application request headers
    }
}

O event objeto contém os cabeçalhos que foram enviados na solicitação do cliente do aplicativo para AWS AppSync.

A função de autorização deve retornar pelo menos isAuthorized um booleano indicando se a solicitação foi autorizada. AWS AppSync reconhece as seguintes chaves retornadas das funções de autorização do Lambda:

Para adicionar uma função do Lambda como o modo de autorização padrão em AWS AppSync:

Console

1. Faça login no AWS AppSync console e navegue até a API que você deseja atualizar.

2. Navegue até a página Configurações da sua API.

   Mude a autorização no nível da API para AWS Lambda.

3. Escolha o ARN Região da AWS e o Lambda para autorizar chamadas de API.

   nota

   A política entidade principal principal apropriada será adicionada automaticamente, permitindo que AWS AppSync chame sua função do Lambda.

4. Opcionalmente, defina o TTL de resposta e a expressão regular de validação de token.

AWS CLI

1. Anexe a seguinte política à função do Lambda que está sendo usada:

   aws lambda add-permission --function-name "my-function" --statement-id "appsync" --principal appsync.amazonaws.com --action lambda:InvokeFunction --output text 

   Importante

   Se você quiser que a política da função seja bloqueada em uma única API GraphQL, você pode executar este comando:

   aws lambda add-permission --function-name “my-function” --statement-id “appsync” --principal appsync.amazonaws.com --action lambda:InvokeFunction --source-arn “<my AppSync API ARN>” --output text

2. Atualize sua AWS AppSync API para usar a função ARN do Lambda fornecida como autorizadora:

   aws appsync update-graphql-api --api-id example2f0ur2oid7acexample --name exampleAPI --authentication-type AWS_LAMBDA --lambda-authorizer-config authorizerUri="arn:aws:lambda:us-east-2:111122223333:function:my-function"

   nota

   Você também pode incluir outras opções de configuração, como a expressão regular do token.

O exemplo a seguir descreve uma função do Lambda que demonstra os vários estados de autenticação e falha que uma função do Lambda pode ter quando usada como mecanismo de autorização do AWS AppSync :

def handler(event, context):
  # This is the authorization token passed by the client
  token = event.get('authorizationToken')
  # If a lambda authorizer throws an exception, it will be treated as unauthorized. 
  if 'Fail' in token:
    raise Exception('Purposefully thrown exception in Lambda Authorizer.')

  if 'Authorized' in token and 'ReturnContext' in token:
    return {
      'isAuthorized': True,
      'resolverContext': {
        'key': 'value'
      }
    }

  # Authorized with no f
  if 'Authorized' in token:
    return {
      'isAuthorized': True
    }
  # Partial authorization
  if 'Partial' in token:
    return {
      'isAuthorized': True,
      'deniedFields':['user.favoriteColor']
    }
  if 'NeverCache' in token:
    return {
      'isAuthorized': True,
      'ttlOverride': 0
    }
  if 'Unauthorized' in token:
    return {
      'isAuthorized': False
    }
  # if nothing is returned, then the authorization fails. 
  return {}

Como contornar as limitações de autorização de tokens do SigV4 e OIDC

Os métodos a seguir podem ser usados para contornar o problema de não ser possível usar sua assinatura do SigV4 ou token do OIDC como seu token de autorização do Lambda quando determinados modos de autorização estão habilitados.

Se você quiser usar a assinatura do SigV4 como token de autorização do Lambda quando os modos de autorização do AWS_IAM e AWS_LAMBDA estiverem habilitados para a API, faça AWS AppSync o seguinte:

Se você quiser usar o token OIDC como o token de autorização Lambda quando o modo de autorização ou os modos de OPENID_CONNECT autorização AMAZON_COGNITO_USER_POOLS e de AWS_LAMBDA autorização estiverem habilitados para a API, AWS AppSync faça o seguinte:

AWS_IAM autorização

Esse tipo de autorização impõe o processo de assinatura versão 4 da assinatura AWS na API GraphQL. Associe políticas de acesso do Identity and Access Management (IAM) com esse tipo de autorização. A aplicação pode aproveitar essa associação ao usar uma chave de acesso (que consiste em um ID de chave de acesso e chave de acesso secreta) ou usando credenciais temporárias de curta duração fornecidas por identidades federadas do Amazon Cognito.

Se quiser um perfil com acesso para realizar todas as operações de dados:

{
   "Version": "2012-10-17",
   "Statement": [
      {
         "Effect": "Allow",
         "Action": [
            "appsync:GraphQL"
         ],
         "Resource": [
            "arn:aws:appsync:us-west-2:123456789012:apis/YourGraphQLApiId/*"
         ]
      }
   ]
}

Você pode encontrar na página principal YourGraphQLApiId de listagem de APIs no AppSync console, diretamente abaixo do nome da sua API. Como alternativa, você pode recuperá-lo com a CLI: aws appsync list-graphql-apis

Se desejar restringir o acesso somente a determinadas operações do GraphQL, faça isso para os campos Query, Mutation e Subscription raiz.

{
   "Version": "2012-10-17",
   "Statement": [
      {
         "Effect": "Allow",
         "Action": [
            "appsync:GraphQL"
         ],
         "Resource": [
            "arn:aws:appsync:us-west-2:123456789012:apis/YourGraphQLApiId/types/Query/fields/<Field-1>",
            "arn:aws:appsync:us-west-2:123456789012:apis/YourGraphQLApiId/types/Query/fields/<Field-2>",
            "arn:aws:appsync:us-west-2:123456789012:apis/YourGraphQLApiId/types/Mutation/fields/<Field-1>",
            "arn:aws:appsync:us-west-2:123456789012:apis/YourGraphQLApiId/types/Subscription/fields/<Field-1>"
         ]
     }
   ]
}

Por exemplo, suponha que tenha o seguinte esquema e deseje restringir o acesso à obtenção de todas as postagens:

schema {
   query: Query
   mutation: Mutation
}

type Query {
   posts:[Post!]!
}

type Mutation {
   addPost(id:ID!, title:String!):Post!
}

A política do IAM correspondente para uma função (que pode ser anexada a um banco de identidades do Amazon Cognito, por exemplo) seria semelhante ao seguinte:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
            "appsync:GraphQL"
            ],
            "Resource": [
                "arn:aws:appsync:us-west-2:123456789012:apis/YourGraphQLApiId/types/Query/fields/posts"
            ]
        }
    ]
}

OPENID_CONNECT autorização

Esse tipo de autorização impõe tokens do OpenID Connect (OIDC) fornecidos por um serviço compatível com o OIDC. O aplicativo pode aproveitar os usuários e os privilégios definidos pelo provedor de OIDC para controlar o acesso.

Um URL emissor é o único valor de configuração obrigatório que deve ser fornecido ao AWS AppSync, por exemplo, https://auth.example.com. Esse URL deve ser endereçável por HTTPS. AWS AppSync /.well-known/openid-configurationanexa ao URL do emissor e localiza a configuração do OpenID de acordo com a especificação do https://auth.example.com/.well-known/openid-configuration OpenID Connect Discovery. Ele espera recuperar um documento JSON RFC5785compatível nesse URL. Esse documento JSON deve conter uma jwks_uri chave, que aponta para o documento JSON Web Key Set (JWKS) com as chaves de assinatura. AWS AppSync exige que o JWKS contenha campos JSON de e. kty kid

AWS AppSync suporta uma ampla variedade de algoritmos de assinatura.

Recomendamos que você use os algoritmos do RSA. Os tokens emitidos pelo provedor devem incluir a hora em que o token foi emitido (iat) e pode incluir a hora em que foi autenticado (auth_time). Você pode fornecer valores de TTL para a hora de emissão (iatTTL) e a hora de autenticação (authTTL) na configuração do OpenID Connect para validação adicional. Se o provedor autoriza vários aplicativos, você também pode fornecer uma expressão regular (clientId) usada para autorizar por ID de cliente. Quando o clientId está presente em sua configuração do OpenID Connect, AWS AppSync valida a declaração exigindo que a corresponda clientId à azp reivindicação aud ou à reivindicação no token.

Para validar vários clientes, IDs use o operador de pipeline (“|”), que é um “ou” na expressão regular. Por exemplo, se seu aplicativo OIDC tiver quatro clientes com cliente, IDs como 0A1S2D, 1F4G9H, 1J6L4B, 6 MG, para validar somente os três primeiros clientes, você colocaria 1F4G9H|1J6L4B|6 GS5 MG no campo ID do cliente. IDs GS5

Autorização do AMAZON_COGNITO_USER_POOLS

Esse tipo de autorização impõe tokens do OIDC fornecidos por grupos de usuários do Amazon Cognito. Seu aplicativo pode aproveitar os usuários e grupos em seus grupos de usuários e grupos de usuários de outra AWS conta e associá-los aos campos do GraphQL para controlar o acesso.

Ao usar grupos de usuários do Amazon Cognito, crie grupos aos quais os usuários pertencem. Essas informações são codificadas em um token JWT para o qual seu aplicativo envia AWS AppSync em um cabeçalho de autorização ao enviar operações do GraphQL. Use diretivas do GraphQL no esquema para controlar quais grupos podem invocar quais resolvedores em um campo, oferecendo acesso mais controlado aos clientes.

Por exemplo, digamos que tenha o seguinte esquema do GraphQL:

schema {
   query: Query
   mutation: Mutation
}

type Query {
   posts:[Post!]!
}

type Mutation {
   addPost(id:ID!, title:String!):Post!
}
...

Se tiver dois grupos em grupos de usuários do Amazon Cognito (blogueiros e leitores) e quiser restringir os leitores para que não possam adicionar novas entradas, o seu esquema deve ser semelhante ao seguinte:

schema {
   query: Query
   mutation: Mutation
}

type Query {
   posts:[Post!]!
   @aws_auth(cognito_groups: ["Bloggers", "Readers"])
}

type Mutation {
   addPost(id:ID!, title:String!):Post!
   @aws_auth(cognito_groups: ["Bloggers"])
}
...

Observe que você pode omitir a @aws_auth diretiva se quiser usar como padrão uma grant-or-deny estratégia específica de acesso. Você pode especificar a grant-or-deny estratégia na configuração do grupo de usuários ao criar sua API GraphQL por meio do console ou por meio do seguinte comando da CLI:

$ aws appsync --region us-west-2 create-graphql-api --authentication-type AMAZON_COGNITO_USER_POOLS  --name userpoolstest --user-pool-config '{ "userPoolId":"test", "defaultEffect":"ALLOW", "awsRegion":"us-west-2"}'

Usar modos de autorização adicionais

Ao adicionar outros modos de autorização, você pode definir diretamente a configuração de autorização no nível da API AWS AppSync GraphQL (ou seja, o authenticationType campo que você pode configurar diretamente no GraphqlApi objeto) e ela atua como padrão no esquema. Isso significa que qualquer tipo que não tenha uma diretiva específica deve passar na configuração de autorização no nível da API.

No nível do esquema, é possível especificar modos de autorização adicionais usando diretivas no esquema. Você pode especificar modos de autorização em campos individuais no esquema. Por exemplo, para autorização API_KEY, você usaria @aws_api_key em definições/campos de tipo de objeto de esquema. As seguintes diretivas são compatíveis com campos de esquema e definições de tipo de objeto:

Não é possível usar a diretiva @aws_auth junto com modos de autorização adicionais. O @aws_auth funciona apenas no contexto de autorização AMAZON_COGNITO_USER_POOLS sem modos de autorização adicionais. No entanto, é possível usar a diretiva @aws_cognito_user_pools no lugar da diretiva @aws_auth, usando os mesmos argumentos. A principal diferença entre as duas é que você pode especificar @aws_cognito_user_pools em qualquer definição de campo e tipo de objeto.

Para entender como os modos de autorização adicionais funcionam e como eles podem ser especificados em um esquema, vamos dar uma olhada no seguinte esquema:

schema {
   query: Query
   mutation: Mutation
}

type Query {
   getPost(id: ID): Post
   getAllPosts(): [Post]
   @aws_api_key
}

type Mutation {
   addPost(
      id: ID!
      author: String!
      title: String!
      content: String!
      url: String!
   ): Post!
}

type Post @aws_api_key @aws_iam {
   id: ID!
   author: String
   title: String
   content: String
   url: String
   ups: Int!
   downs: Int!
   version: Int!
}
...

Para esse esquema, suponha que esse AWS_IAM seja o tipo de autorização padrão na API AWS AppSync GraphQL. Isso significa que os campos que não têm uma diretiva são protegidos usando o AWS_IAM. Por exemplo, esse é o caso do campo getPost no tipo Query. As diretivas de esquema permitem que você use mais de um modo de autorização. Por exemplo, você pode ter API_KEY configurado como um modo de autorização adicional na API AWS AppSync GraphQL e pode marcar um campo usando a @aws_api_key diretiva (por exemplo, getAllPosts neste exemplo). As diretivas funcionam no nível do campo, portanto, também é necessário conceder a API_KEY acesso ao tipo Post. Você pode fazer isso marcando cada campo no tipo Post com uma diretiva ou marcando o tipo Post com a diretiva @aws_api_key.

Para restringir ainda mais o acesso aos campos no tipo Post, é possível usar diretivas em relação a campos individuais no tipo Post, conforme mostrado a seguir.

Por exemplo, é possível adicionar um campo restrictedContent ao tipo Post e restringir o acesso a ele usando a diretiva @aws_iam. As solicitações AWS_IAM autenticadas podem acessar restrictedContent, no entanto, as solicitações API_KEY não podem acessá-lo.

type Post @aws_api_key @aws_iam{
   id: ID!
   author: String
   title: String
   content: String
   url: String
   ups: Int!
   downs: Int!
   version: Int!
   restrictedContent: String!
   @aws_iam
}
...

Controle de acesso refinado

As informações anteriores demonstram como restringir ou conceder acesso a determinados campos do GraphQL. Se deseja definir controles de acesso nos dados com base em determinadas condições (por exemplo, com base no usuário que está fazendo uma chamada e se o usuário é proprietário dos dados), você pode usar modelos de mapeamento nos resolvedores. Também é possível executar lógica de negócios mais complexa, descrita em Filtrar informações.

Essa seção mostra como definir controles de acesso nos dados usando um modelo de mapeamento de resolvedor do DynamoDB.

Antes de prosseguir, se você não estiver familiarizado com os modelos de mapeamento em AWS AppSync, talvez queira revisar a referência do modelo de mapeamento do Resolver e a referência do modelo de mapeamento do Resolver para o DynamoDB.

No exemplo a seguir que usa o DynamoDB, suponha que você esteja usando o esquema de publicação de blog anterior e somente usuários que criaram uma publicação possam editá-lo. O processo de avaliação seria o usuário obter credenciais no seu aplicativo, usando Grupos de usuários do Amazon Cognito por exemplo e, em seguida, enviar essas credenciais como parte de uma operação do GraphQL. Em seguida, o modelo de mapeamento substituirá um valor das credenciais (como o nome do usuário) em uma instrução condicional que então será comparado a um valor do banco de dados.

Para adicionar essa funcionalidade, adicione um campo do GraphQL editPost da seguinte forma:

schema {
   query: Query
   mutation: Mutation
}

type Query {
   posts:[Post!]!
}

type Mutation {
   editPost(id:ID!, title:String, content:String):Post
   addPost(id:ID!, title:String!):Post!
}
...

O modelo de mapeamento do resolvedor editPost (mostrado em um exemplo no final dessa seção) precisa executar uma verificação lógica no armazenamento de dados para permitir que apenas o usuário que criou uma publicação possa editá-la. Como essa é uma operação de edição, ela corresponde a um UpdateItem no DynamoDB. Execute uma verificação condicional antes de executar essa ação, usando o contexto enviado para a validação de identidade do usuário. Isso é armazenado em um objeto Identity com os seguintes valores:

{
   "accountId" : "12321434323",
   "cognitoIdentityPoolId" : "",
   "cognitoIdentityId" : "",
   "sourceIP" : "",
   "caller" : "ThisistheprincipalARN",
   "username" : "username",
   "userArn" : "Sameasabove"
}

Para usar esse objeto em uma chamada do UpdateItem do DynamoDB, é necessário armazenar as informações sobre a identidade do usuário na tabela para comparação. Primeiro, a mutação addPost precisa armazenar o criador. Em segundo lugar, a mutação editPost precisa executar a verificação condicional antes de atualizar.

Veja aqui um exemplo de código de resolvedor para addPost que armazena a identidade do usuário como uma coluna Author:

import { util, Context } from '@aws-appsync/utils';
import { put } from '@aws-appsync/utils/dynamodb';

export function request(ctx) {
	const { id: postId, ...item } = ctx.args;
	return put({
		key: { postId },
		item: { ...item, Author: ctx.identity.username },
		condition: { postId: { attributeExists: false } },
	});
}

export const response = (ctx) => ctx.result;

Observe que o atributo Author é preenchido a partir do objeto Identity, que veio do aplicativo.

Por fim, veja um exemplo do código de resolvedor para editPost, que atualizará apenas o conteúdo da publicação de blog se a solicitação vier do usuário que criou a publicação:

import { util, Context } from '@aws-appsync/utils';
import { put } from '@aws-appsync/utils/dynamodb';

export function request(ctx) {
	const { id, ...item } = ctx.args;
	return put({
		key: { id },
		item,
		condition: { author: { contains: ctx.identity.username } },
	});
}

export const response = (ctx) => ctx.result;

Este exemplo usa um PutItem que substitui todos os valores em vez de um UpdateItem, mas o mesmo conceito se aplica ao bloco de declarações condition.

Filtrar informações

Pode haver casos onde não é possível controlar a resposta da fonte de dados, mas você não deseja enviar informações desnecessárias aos clientes sobre uma gravação ou leitura bem-sucedida da fonte de dados. Nesses casos, você pode filtrar as informações usando um modelo de mapeamento de resposta.

Por exemplo, suponha que você não tenha um índice apropriado na tabela do DynamoDB da publicação de blog (como um índice em Author). É possível usar o seguinte resolvedor:

import { util, Context } from '@aws-appsync/utils';
import { get } from '@aws-appsync/utils/dynamodb';

export function request(ctx) {
	return get({ key: { ctx.args.id } });
}

export function response(ctx) {
	if (ctx.result.author === ctx.identity.username) {
		return ctx.result;
	}
	return null;
}

O manipulador de solicitações busca o item mesmo que o chamador não seja o autor que criou a publicação. Para evitar que isso exiba todos os dados, o manipulador de respostas verifica se o chamador corresponde ao autor do item. Se o chamador não corresponder a essa verificação, apenas uma resposta nula é retornada.

Acesso à fonte de dados

AWS AppSync se comunica com fontes de dados usando funções e políticas de acesso do Identity and Access Management (IAM). Se você estiver usando uma função existente, uma Política de Confiança precisará ser adicionada AWS AppSync para que você possa assumir a função. A relação de confiança terá a seguinte aparência:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "appsync.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

É importante restringir a política de acesso no perfil para ter permissões apenas para atuar sobre o conjunto mínimo de recursos necessários. Ao usar o AppSync console para criar uma fonte de dados e criar uma função, isso é feito automaticamente para você. No entanto, ao usar um modelo de exemplo integrado do console do IAM para criar uma função fora do console do AWS AppSync, as permissões não serão restringidas automaticamente em um recurso e você deve executar essa ação antes de mover o aplicativo para produção.