翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
GraphQL を保護するための認証と認可の設定 APIs
AWS AppSync では、GraphQL をセキュア化するために、APIsAPIキー、Lambda、、IAMOpenID Connect、および Cognito ユーザープールの認証タイプを提供しています。各オプションは、異なるセキュリティ方法を提供します。
-
API キー認証: 認証されていない のスロットリングを制御しAPIs、シンプルなセキュリティオプションを提供します。
-
Lambda 認証: カスタム認証ロジックを有効にし、関数の入力と出力を詳細に説明します。
-
IAM 認証 : AWSの署名バージョン 4 の署名プロセスを使用し、IAMポリシーによるきめ細かなアクセスコントロールを可能にします。
-
OpenID Connect 認証: ユーザー認証用の OIDC準拠サービスと統合します。
-
Cognito ユーザープール: Cognito のユーザー管理機能を使用してグループベースのアクセスコントロールを実装します。
認証タイプ
アプリケーションが GraphQL とやり取りすることを許可するには、5 つの方法があります AWS AppSyncAPI。使用する認証タイプを指定するには、 または CLI呼び出しで次の認証タイプ値のいずれかを指定します AWS AppSync API。
-
-
API_KEY
-
API キーを使用する場合。
-
-
-
AWS_LAMBDA
-
AWS Lambda 関数を使用する場合。
-
-
-
AWS_IAM
-
AWS Identity and Access Management (IAM
) アクセス許可を使用する場合。
-
-
-
OPENID_CONNECT
-
OpenID Connect プロバイダーを使用する場合。
-
-
-
AMAZON_COGNITO_USER_POOLS
-
Amazon Cognito ユーザープールを使用する場合。
-
これらの基本的な承認タイプは、ほとんどの開発者に有効です。より高度なユースケースでは、コンソール、、CLIおよび を使用して追加の認証モードを追加できます AWS CloudFormation。追加の認証モードの場合、 は、上記の値 (、、、AWS_LAMBDA
、AWS_IAM
OPENID_CONNECT
) API_KEY
を取得する認証タイプ AWS AppSync を提供しますAMAZON_COGNITO_USER_POOLS
。
メインまたはデフォルトの承認タイプとしてAPI_KEY
、AWS_LAMBDA
、または AWS_IAM
を指定した場合、それを追加の承認モードの 1 つとして再び指定することはできません。同様に、追加の承認モード間で API_KEY
、AWS_LAMBDA
、または AWS_IAM
を重複して使用することはできません。複数の Amazon Cognito ユーザープールと OpenID Connect プロバイダーを使用できます。ただし、デフォルトの承認モードと追加の承認モード間で Amazon Cognito ユーザープールまたは OpenID Connect プロバイダーを重複して使用することはできません。Amazon Cognito ユーザープールまたは OpenID Connect プロバイダーに異なる複数のクライアントを設定する場合、対応する正規表現を使用できます。
API_KEY 認証
認証されていない には、認証された よりも厳密なスロットリングAPIsが必要ですAPIs。認証されていない GraphQL エンドポイントのスロットリングを制御する 1 つの方法は、 APIキーを使用することです。API キーは、認証されていない GraphQL エンドポイントを作成するときに AWS AppSync サービスによって生成されるアプリケーション内のハードコードされた値です。コンソール、、CLIまたはAWS AppSync APIリファレンス からAPIキーをローテーションできます。
API キーは最大 365 日間設定でき、既存の有効期限をその日から最大 365 日間延長できます。API キーは、開発目的またはパブリック を公開しても安全なユースケースに推奨されますAPI。
クライアントでは、APIキーはヘッダー で指定されますx-api-key
。
たとえば、API_KEY
が 'ABC123'
である場合、次のように curl
経由で GraphQL クエリを送信できます。
$ curl -XPOST -H "Content-Type:application/graphql" -H "x-api-key:ABC123" -d '{ "query": "query { movies { id } }" }' https://YOURAPPSYNCENDPOINT/graphql
AWS_LAMBDA 認証
AWS Lambda 関数を使用して独自のAPI認証ロジックを実装できます。プライマリオーソライザーまたはセカンダリオーソライザーのいずれかに Lambda 関数を使用できますが、 ごとに 1 つの Lambda 認証関数しか存在しない場合がありますAPI。Lambda 関数を認証に使用する場合、次のことが適用されます。
-
API で
AWS_LAMBDA
およびAWS_IAM
認証モードが有効になっている場合、SigV4 署名をAWS_LAMBDA
認証トークンとして使用することはできません。 -
API で
AWS_LAMBDA
およびOPENID_CONNECT
認証モードまたはAMAZON_COGNITO_USER_POOLS
認証モードが有効になっている場合、OIDCトークンをAWS_LAMBDA
認証トークンとして使用することはできません。OIDC トークンはベアラースキームである可能性があることに注意してください。 -
Lambda 関数は、リゾルバーに対して 5MB を超えるコンテキストデータを返してはいけません。
たとえば、認証トークン が 'ABC123'
である場合、次のように curl 経由で GraphQL クエリを送信できます。
$ curl -XPOST -H "Content-Type:application/graphql" -H "Authorization:ABC123" -d '{ "query": "query { movies { id } }" }' https://YOURAPPSYNCENDPOINT/graphql
Lambda 関数は、各クエリまたはミューテーションの前に呼び出されます。戻り値は、APIID と認証トークンに基づいてキャッシュできます。デフォルトでは、キャッシュはオンになっていませんが、これは APIレベルで有効にすることも、関数の戻りttlOverride
値に 値を設定することで有効にすることもできます。
必要に応じて、関数が呼び出される前に認証トークンを検証する正規表現を指定できます。これらの正規表現は、関数が呼び出される前に、認証トークンが正しい形式であることを検証するために使用されます。この正規表現と一致しないトークンを使用したリクエストは、自動的に拒否されます。
認証に使用される Lambda 関数には、 appsync.amazonaws.com
がそれらを AWS AppSync 呼び出すことができるように、 のプリンシパルポリシーを適用する必要があります。このアクションは AWS AppSync コンソールで自動的に実行されます。 AWS AppSync コンソールはポリシーを削除しません。Lambda 関数にポリシーをアタッチする方法の詳細については、「 AWS Lambda デベロッパーガイド」の「リソースベースのポリシー」を参照してください。
指定した Lambda 関数は次の形状のイベントを受け取ります。
{ "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
} }
event
オブジェクトには、アプリケーションクライアントから へのリクエストで送信されたヘッダーが含まれています AWS AppSync。
認証関数は少なくとも を返す必要があります。これはisAuthorized
、リクエストが認証されているかどうかを示すブール値です。Lambda 認証関数から返される次のキー AWS AppSync を認識します。
isAuthorized
(boolean、必須)-
の値が GraphQL への呼び出し
authorizationToken
を許可するかどうかを示すブール値API。この値が true の場合、GraphQL の実行はAPI続行されます。この値が false の場合、
UnauthorizedException
が生成されます。 deniedFields
(文字列のリスト、オプション)-
リゾルバーから値が返された場合でも、そのリストは強制的に
null
に変更されます。各項目は、 ARNの形式の完全修飾フィールド
arn:aws:appsync:
または の短い形式のいずれかですus-east-1
:111122223333
:apis/GraphQLApiId
/types/TypeName
/fields/FieldName
。完全なARN形式は、2 つの が Lambda 関数オーソライザーAPIsを共有し、2 つの 間で共通のタイプとフィールドの間にあいまいさがある可能性がある場合に使用しますAPIs。TypeName
.FieldName
resolverContext
(JSON オブジェクト、オプション)-
リゾルバーテンプレート
$ctx.identity.resolverContext
で として表示されるJSONオブジェクト。たとえば、リゾルバーによって次の構造体が返されたとします。{ "isAuthorized":true "resolverContext": { "banana":"very yellow", "apple":"very green" } }
リゾルバーテンプレート内の値
ctx.identity.resolverContext.apple
は「very green
」になります。resolverContext
オブジェクト はキーと値のペアのみをサポートします。ネストされたキーはサポートされません。警告
このJSONオブジェクトの合計サイズは 5MBを超えることはできません。
ttlOverride
(integer、オプション)-
応答をキャッシュする秒数。値が返されない場合は、 の値APIが使用されます。これが 0 の場合、応答はキャッシュされません。
Lambda オーソライザーのタイムアウトは 10 秒です。のパフォーマンスをスケーリングするために、できるだけ短い時間で実行する関数を設計することをお勧めしますAPI。
複数の AWS AppSync APIs が 1 つの認証 Lambda 関数を共有できます。クロスアカウントオーソライザーの使用は許可されていません。
複数の 間で認証関数を共有する場合APIs、短い形式のフィールド名 (
) が誤ってフィールドを非表示にする可能性があることに注意してください。でフィールドのあいまいさを解消するにはtypename
.fieldname
deniedFields
、 のARN形式であいまいなフィールドを指定できますarn:aws:appsync:
。region
:accountId
:apis/GraphQLApiId
/types/typeName
/fields/fieldName
AWS AppSyncで Lambda 関数をデフォルトの認証モードとして追加するには、
次の例では、Lambda 関数が AWS AppSync 認証メカニズムとして使用されたとき、その Lambda 関数が持つさまざまな認証状態および認証失敗状態を示しています。
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 {}
SigV4 とOIDCトークン認証の制限を回避する
特定の認証モードが有効になっている場合、SigV4 署名またはOIDCトークンを Lambda 認証トークンとして使用できない問題を回避するために、次の方法を使用できます。
の で AWS_IAM
および 認証モードが有効になっているときに、SigV4 AWS AppSync署名を Lambda AWS_LAMBDA
認証トークンとして使用する場合はAPI、次の手順を実行します。
-
新しい Lambda 認証トークンを作成するには、SigV4 署名にランダムなサフィックスおよび/またはプレフィックスを追加します。
-
元の SigV4 署名を取得するには、Lambda 認証トークンからランダムなプレフィックスおよび/またはサフィックスを削除して、Lambda 関数を更新します。次に、元の SigV4 署名を認証に使用します。
の で認証モードまたは AMAZON_COGNITO_USER_POOLS
および OPENID_CONNECT
認証モードが有効になっているときに、OIDCトークンを Lambda AWS_LAMBDA
認証トークンとして使用する場合は AWS AppSync API、次の手順を実行します。
-
新しい Lambda 認証トークンを作成するには、OIDCトークンにランダムなサフィックスやプレフィックスを追加します。Lambda 認証トークンにはベアラースキームプレフィックスを含めないでください。
-
元のOIDCトークンを取得するには、Lambda 認証トークンからランダムなプレフィックスやサフィックスを削除して Lambda 関数を更新します。次に、認証に元のOIDCトークンを使用します。
AWS_IAM 認証
この認証タイプは、AWS GraphQL の署名バージョン 4 の署名プロセスを強制しますAPI。 GraphQL Identity and Access Management (IAM
すべてのデータオペレーションを実行できるアクセス権限を持つロールが必要な場合。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "appsync:GraphQL" ], "Resource": [ "arn:aws:appsync:us-west-2:123456789012:apis/YourGraphQLApiId/*" ] } ] }
コンソールのメインAPIリストページYourGraphQLApiId
AppSyncから、 の名前を直接確認できますAPI。または、 を使用して取得することもできますCLI。 aws appsync list-graphql-apis
特定の GraphQL オペレーションのみにアクセスを制限するには、ルートの Query
、Mutation
、Subscription
の各フィールドに対してこれを実行します。
{ "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>" ] } ] }
たとえば、以下のスキーマがあり、すべての投稿を取得するアクセスを制限する場合。
schema { query: Query mutation: Mutation } type Query { posts:[Post!]! } type Mutation { addPost(id:ID!, title:String!):Post! }
ロールに対応するIAMポリシー (Amazon Cognito ID プールにアタッチできるポリシーなど) は次のようになります。
{ "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 認証
この認証タイプは、 OIDC準拠のサービスによって提供される OpenID 接続
発行者は、指定する唯一の必須設定値URLです AWS AppSync (例: https://auth.example.com
)。これは、発行者HTTPS AWS AppSync /.well-known/openid-configuration
に追加URLし、OpenID Connect Discovery 仕様https://auth.example.com/.well-known/openid-configuration
に従って で OpenID 設定を見つけることで対処できるURL必要があります。 OpenID jwks_uri
キーを持つJSONウェブキーセット (JWKS) ドキュメントを指すキーが含まれている必要があります。 AWS AppSync には kty
および のJSONフィールドJWKSが含まれている必要がありますkid
。
AWS AppSync は、さまざまな署名アルゴリズムをサポートしています。
署名アルゴリズム |
---|
RS256 |
RS384 |
RS512 |
PS256 |
PS384 |
PS512 |
HS256 |
HS384 |
HS512 |
ES256 |
ES384 |
ES512 |
RSA アルゴリズムを使用することをお勧めします。プロバイダーによって発行されたトークンに、トークンが発行された時刻 (iat
) が含まれている必要があり、認証された時刻 (auth_time
) が含まれる場合があります。OpenID Connect 設定で発行時刻 (iatTTL
) と認証時刻 (authTTL
) TTLの値を指定して、追加の検証を行うことができます。使用するプロバイダーが複数のアプリケーションを認証している場合は、クライアント ID で認証するために使用される正規表現を (clientId
) も入力できます。clientId
が OpenID Connect 設定に存在する場合、 は、 clientId
をトークン内の aud
または クレームのいずれかと一致させることでazp
、 クレーム AWS AppSync を検証します。
複数のクライアントを検証するには、正規表現の「または」であるパイプライン演算子 (「|」) IDsを使用します。例えば、OIDCアプリケーションに 0A1S2D、1F4G9H、1J6L4B、6 IDsなどのクライアントを持つ 4 つのクライアントがありGS5MG、最初の 3 つのクライアント のみを検証する場合IDs、クライアント ID フィールドに 1F4G9H |1J6L4B|6GS5MG を配置します。 0A1S2D, 1F4G9H, 1J6L4B
AMAZON_COGNITO_USER_POOLS 認証
この認証タイプは、Amazon Cognito ユーザープールによって提供されるOIDCトークンを適用します。アプリケーションは、別のアカウントのユーザープールとユーザープールの両方のユーザーとグループを活用し AWS 、これらを GraphQL フィールドに関連付けてアクセスを制御できます。
Amazon Cognito ユーザープールを使用する場合、ユーザーが属するグループを作成できます。この情報は、GraphQL オペレーションを送信するときにアプリケーションが認証ヘッダー AWS AppSync で に送信するJWTトークンにエンコードされます。スキーマで GraphQL ディレクティブを使用して、フィールドでどのグループがどのリゾルバーを起動できるのかを制御します。したがってカスタマーのアクセスを細かく制御できます。
たとえば、以下の GraphQL スキーマがあるとします。
schema { query: Query mutation: Mutation } type Query { posts:[Post!]! } type Mutation { addPost(id:ID!, title:String!):Post! } ...
Amazon Cognito ユーザープールに 2 つのグループ (bloggers と readers) があり、readers が新しいエントリを追加できないように制限する場合、スキーマは次のようになります。
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"]) } ...
アクセスに関する特定の grant-or-deny 戦略をデフォルトにする場合は、 @aws_auth
ディレクティブを省略できます。GraphQL を作成するときに、コンソールまたは次のCLIコマンドAPIを使用して、ユーザープール設定で grant-or-deny 戦略を指定できます。
$ 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"}'
追加の承認モードの使用
追加の認証モードを追加すると、 AWS AppSync GraphQL APIレベル (GraphqlApi
オブジェクトで直接設定できる authenticationType
フィールド) で認証設定を直接設定でき、スキーマのデフォルトとして機能します。つまり、特定のディレクティブを持たないタイプは、APIレベル認証設定に合格する必要があります。
スキーマレベルでは、スキーマでディレクティブを使用して追加の承認モードを指定できます。スキーマの個々のフィールドに承認モードを指定できます。たとえば、API_KEY
承認の場合、スキーマオブジェクトタイプの定義/フィールドで @aws_api_key
を使用します。以下のディレクティブは、スキーマフィールドおよびオブジェクトタイプ定義でサポートされています。
-
@aws_api_key
- フィールドがAPI_KEY
で承認されることを指定します。 -
@aws_iam
- フィールドがAWS_IAM
で承認されることを指定します。 -
@aws_oidc
- フィールドがOPENID_CONNECT
で承認されることを指定します。 -
@aws_cognito_user_pools
- フィールドがAMAZON_COGNITO_USER_POOLS
で承認されることを指定します。 -
@aws_lambda
- フィールドがAWS_LAMBDA
で承認されることを指定します。
@aws_auth
ディレクティブを追加の承認モードと共に使用することはできません。@aws_auth
は、追加の承認モードのない AMAZON_COGNITO_USER_POOLS
承認のコンテキストでのみ機能します。ただし、同じ引数で @aws_auth
ディレクティブの代わりに @aws_cognito_user_pools
ディレクティブを使用できます。2 つの主な違いは、フィールドとオブジェクトタイプの定義で @aws_cognito_user_pools
を指定できることです。
追加の承認モードがどのように機能し、スキーマでどのように指定できるかを理解するために、以下のスキーマを見てみましょう。
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! } ...
このスキーマでは、 AWS_IAM
が AWS AppSync GraphQL のデフォルトの認証タイプであると仮定しますAPI。つまり、ディレクティブのないフィールドは AWS_IAM
を使用して保護されます。たとえば、Query
タイプの getPost
フィールドの場合です。スキーマディレクティブにより、複数の承認モードを使用できます。例えば、 を AWS AppSync GraphQL の追加認証モードとしてAPI_KEY
設定しAPI、 @aws_api_key
ディレクティブ (getAllPosts
この例では など) を使用してフィールドをマークできます。ディレクティブはフィールドレベルで機能するため、Post
タイプへの API_KEY
アクセスも許可する必要があります。そのためには、Post
タイプの各フィールドをディレクティブでマークするか、Post
タイプを @aws_api_key
ディレクティブでマークします。
Post
タイプのフィールドへのアクセスをさらに制限するには、以下に示すように、Post
タイプの個々のフィールドに対してディレクティブを使用できます。
たとえば、restrictedContent
フィールドを Post
タイプに追加し、@aws_iam
ディレクティブを使用してそのフィールドへのアクセスを制限できます。ただし restrictedContent
に、AWS_IAM
認証済みリクエストからはアクセスできますが、API_KEY
リクエストからはアクセスできません。
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 } ...
きめ細かなアクセスコントロール
前述の情報は、特定の GraphQL フィールドへのアクセスを制限または許可する方法を示しています。特定の条件に基づいて (たとえば、呼び出し元のユーザーがだれであるかや、そのユーザーがデータを所有しているかどうかに基づいて) データに対するアクセスコントロールを設定する場合は、リゾルバーでマッピングテンプレートを使用できます。より複雑なビジネスロジックも実行できます。「フィルタ処理情報」で説明します。
このセクションでは、DynamoDB リゾルバーマッピングテンプレート使用してデータのアクセスコントロールを設定する方法を示します。
先に進む前に、 のマッピングテンプレートに慣れていない場合は AWS AppSync、DynamoDB の「リゾルバーマッピングテンプレートリファレンス」と「リゾルバーマッピングテンプレートリファレンス」を確認してください。 DynamoDB
DynamoDB を使用した次の例では、前述のブログ投稿スキーマを使用し、投稿を作成したユーザーのみが編集を許可されているものとします。評価プロセスは、Amazon Cognito ユーザープールなどを使用して、ユーザーがアプリケーションで認証情報を取得し、GraphQL オペレーションの一部として、これらの認証情報を渡すというものです。その後、マッピングテンプレートが、条件ステートメントで、認証情報 (username など) からの値を置き換えます。値はデータベースの値と比較されます。
この機能を追加するには、次のように editPost
GraphQL フィールドを追加します。
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! } ...
editPost
のリゾルバーマッピングテンプレート (このセクションの最後にある例) では、投稿を作成したユーザーのみが編集を許可されるように、データストアに対する論理チェックを実行する必要があります。これは編集オペレーションなので、DynamoDB の UpdateItem
に対応します。ユーザー ID 検証に渡されるコンテキストを使用して、このアクションを実行する前に条件チェックを実行できます。これは次の値を持つ Identity
オブジェクトに保存されます。
{ "accountId" : "12321434323", "cognitoIdentityPoolId" : "", "cognitoIdentityId" : "", "sourceIP" : "", "caller" : "ThisistheprincipalARN", "username" : "username", "userArn" : "Sameasabove" }
DynamoDB UpdateItem
コールでこのオブジェクトを使用するには、比較用テーブルにユーザー ID 情報を保存する必要があります。まず、addPost
ミューテーションは作成者を保存する必要があります。次に、更新する前に、editPost
ミューテーションで条件チェックを実行する必要があります。
Author
列としてユーザー ID を保存する addPost
のリゾルバーコードの例を次に示します。
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;
Author
属性が、アプリケーションから得られた Identity
オブジェクトから入力されていることに注意してください。
最後に、editPost
のリゾルバーコードの例を次に示します。これは、投稿を作成したユーザーからリクエストが来た場合にのみ、ブログ投稿のコンテンツを更新します。
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;
この例では、UpdateItem
ではなく、すべての値を上書きする PutItem
を使用していますが、condition
ステートメントブロックには同じ概念が適用されます。
フィルタ処理情報
データソースからのレスポンスを制御できないときに、データソースへの正常な書き込みまたは読み取りに対して、不必要な情報をクライアントに送信したくない場合があります。このような場合は、レスポンスマッピングテンプレートを使用して情報をフィルタリングすることができます。
たとえば、ブログ投稿 DynamoDB テーブルに適切なインデックス (Author
のインデックスなど) がない場合を考えます。以下のリゾルバーを使用できます。
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; }
リクエストハンドラは、呼び出し元が投稿の作成者でなくても、項目をフェッチします。これによってすべてのデータが返されるのを防ぐために、レスポンスハンドラは呼び出し元が項目の作成者と一致することを確認します。発信者がこのチェックに一致しない場合に、null レスポンスのみが返されます。
データソースへのアクセス
AWS AppSync は Identity and Access Management (IAM
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "appsync.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
必要な最小限のリソースについて作業を行うアクセス許可のみを持つように、ロールのアクセスポリシーを制限することが重要です。 AppSync コンソールを使用してデータソースを作成し、ロールを作成すると、自動的に実行されます。ただし、IAMコンソールから組み込みサンプルテンプレートを使用してコンソールの AWS AppSync外部でロールを作成する場合、アクセス許可はリソースに自動的にスコープダウンされないため、アプリケーションを本番環境に移行する前にこのアクションを実行する必要があります。