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 GraphQLAPIs: API keys, Lambda, IAM OpenID Connect e Cognito User Pools. Cada opção fornece um método diferente de segurança:

Tipos de autorização

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

Esses tipos de autorização básicos funcionam para a maioria dos desenvolvedores. Para casos de uso mais avançados, você pode adicionar outros modos de autorização por meio do consoleCLI, do AWS CloudFormation e. 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_KEYautorização

Os não autenticados APIs exigem uma limitação mais rígida do que os autenticados. APIs Uma forma de controlar a limitação de endpoints GraphQL não autenticados é por meio do uso de chaves. API Uma API chave é um valor codificado em seu aplicativo que é gerado pelo AWS AppSync serviço quando você cria um endpoint GraphQL não autenticado. Você pode girar API as teclas do consoleCLI, do ou da AWS AppSync APIreferência.

Console

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

   1. No APIspainel, escolha seu GraphQLAPI.

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

2. Em Modo de autorização padrão, escolha a APIchave.

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

   Uma nova API chave será gerada na tabela.

   1. Para excluir uma API chave antiga, selecione a API chave 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 ao AWS CLI. Para obter mais informações, consulte Noções básicas de configuração.

2. Crie um API objeto GraphQL executando o update-graphql-apicomando.

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

   1. O api-id do seu GraphQLAPI.

   2. O novo name do seuAPI. Você pode usar o mesmo name.

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

   nota

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

   Veja um exemplo de comando:

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

   Uma saída será retornada noCLI. Aqui está um exemplo emJSON:

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

APIas chaves são configuráveis por até 365 dias, e você pode estender uma data de expiração existente por até mais 365 dias a partir desse dia. APIAs chaves são recomendadas para fins de desenvolvimento ou casos de uso em que é seguro expor um públicoAPI.

No cliente, a API chave é especificada pelo cabeçalhox-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_LAMBDAautorização

Você pode implementar sua própria lógica de API autorização usando uma AWS Lambda função. Você pode usar uma função Lambda para seu autorizador primário ou secundário, mas pode haver apenas uma função de autorização 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 API ID e no token de autenticação. Por padrão, o armazenamento em cache não está ativado, mas isso pode ser ativado no API nível ou definindo o ttlOverride valor 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é o API que você deseja atualizar.

2. Navegue até a página de configurações do seuAPI.

   Altere a autorização API -Level para AWS Lambda.

3. Escolha o Região da AWS e o Lambda ARN para autorizar chamadas. 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 a expressão regular de validação de resposta TTL e 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 um único GraphQLAPI, 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 seu AWS AppSync API para usar a função Lambda fornecida ARN 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 do SigV4 e do token OIDC

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

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

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

AWS_IAMautorização

Esse tipo de autorização impõe o processo de AWS assinatura da versão 4 no GraphQLAPI. Você pode associar políticas de acesso do Identity and Access Management (IAM) a 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 do API anúncio no AppSync console, diretamente abaixo do nome do seuAPI. Como alternativa, você pode recuperá-lo com: 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 IAM política correspondente para uma função (que você poderia anexar a um pool de identidade do Amazon Cognito, por exemplo) teria a seguinte aparência:

{
    "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 OpenID connect OIDC () fornecidos por OIDC um serviço compatível. Seu aplicativo pode aproveitar os usuários e os privilégios definidos pelo seu OIDC provedor para controlar o acesso.

Um emissor URL é o único valor de configuração necessário que você fornece para AWS AppSync (por exemplo,https://auth.example.com). Isso URL deve ser endereçável novamente. HTTPS AWS AppSync /.well-known/openid-configurationanexa ao emissor URL e localiza a configuração do OpenID de acordo com a especificação do OpenID Connect https://auth.example.com/.well-known/openid-configuration Discovery. Ele espera recuperar um JSON documento RFC5785compatível com isso. URL Esse JSON documento 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 JWKS o contenha JSON campos de kty kid e.

AWS AppSync suporta uma ampla variedade de algoritmos de assinatura.

Recomendamos que você use os RSA algoritmos. 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 TTL valores para a hora emitida (iatTTL) e a hora da 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 OIDC aplicativo tiver quatro clientes com um cliente, IDs como 0A1S2D, 1F4G9H, 1J6L4B, 6, para validar somente os três primeiros clientes, você colocaria 1F4G9H|1J6L4B|6 GS5MG no campo ID do cliente. IDs GS5MG

AMAZON_COGNITO_USER_POOLS autorização

Esse tipo de autorização impõe OIDC tokens fornecidos pelos 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 JWT token que 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 seu GraphQL API por meio do console ou por meio do seguinte comando: 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 API nível do 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 precisa passar pela configuração de autorização de API nível.

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 AWS_IAM seja o tipo de autorização padrão no AWS AppSync GraphQLAPI. 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 no AWS AppSync GraphQL API 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 amostra incorporado do IAM console para criar uma função fora do AWS AppSync console, as permissões não serão automaticamente reduzidas ao escopo de um recurso, e você deve realizar essa ação antes de mover seu aplicativo para produção.