2017-04-07 21 views
1

登録を確認したら、cognitoユーザーのユーザーレコードをddbに作成しようとしています。私は主キーとしてユーザーの(フェデレーションされた)ID IDを使用したいと思います。AWS Cognito - ユーザーが登録を確認した後、dynamodbでユーザーレコードを作成する方法

ただし、識別IDはpostConfirmationラムダトリガーでは使用できません。実際には、ユーザーがアクセストークンで認証するまで、ID IDは使用できません。私は、これは、コグニートのユーザープールがFacebookやGoogleのようなプロバイダーであることを考えると理にかなっていると思います。そのプロバイダでログインするまでは、IDを作成しません。

facebookとgoogleとは異なり、Cognitoのユーザープールにサインインするときにヒットするレコードを作成するoauthコールバックはありません。ユーザーは次のようにサインインするだけです。

cognitoUser.authenticateUser(authenticationDetails, { 
    onSuccess: function (result) { 
     console.log('access token + ' + result.getAccessToken().getJwtToken()); 
     AWS.config.credentials = new AWS.CognitoIdentityCredentials({ 
      IdentityPoolId: self.IdentityPoolId, 
      Logins: { 
       [`cognito-idp.${self.region}.amazonaws.com/${self.poolData.UserPoolId}`]: result.getIdToken().getJwtToken() 
      } 
     }); 
     console.log("AuthService: set the AWS credentials - " + JSON.stringify(AWS.config.credentials)); 
     self.currentUser = cognitoUser; 
     cb(null, result); 
    }, 

    onFailure: function(err) { 
     console.log(err); 
     cb(err, null); 
    } 

}); 

作成されたIDは、そのときだけです。ユーザーレコードの作成を実装する標準的な方法は何ですか?ユーザーが最初にサインインしたときにレコードを作成するのが標準ですか?

答えて

2

これを行うにはいくつかの方法があります。 IDの代わりにサブ値をキーとして使用することがあります。これは作成時にユーザーに与えられ、グローバルに一意(ID IDなど)です。このルートに進むと、postConfirmationコールバックの使用についてのあなたの考えは素晴らしいです。

アイデンティティID(他のAWSリソースにアクセスしてアクセスしたい場合など)が必要な場合は、そこのonSuccessブロックに独自のフックを作成することをおすすめします。そのアイデンティティIDの行が存在するかどうかを確認し、存在する場合は何もしないでください。そうでない場合は作成してください。あなたのユースケースには意味がありますか?またはもっとシワがありますか?

+0

私の使用例は、/ users /:id/projectsのようなapiゲートウェイエンドポイントを持つことで、ユーザーのすべてのプロジェクトを取得します。サブ値やIDを使用する方が簡単でしょうか?アイデンティティIDを考えていた。 – user1411469

+0

ユーザープールには、API GWとの緊密な統合があります。 API GWの背後にあるすべてをマッピングする場合は、代わりにsubを使用できます。代わりにアイデンティティIDを使用すると、クライアントからDynamoのようなものに直接アクセスしたい場合にはうまく機能します。どちらの場合でも仕事はかなり似ていると思います。 –

+0

グローバルにユニークなことは、サブシステムがすべてのユーザープールで一意であることを意味しますか? – user1411469

関連する問題