これであとで渡すtokenが他のアプリに発行されたものじゃないことが確認される。Policyを選択する。3で作成したポリシーをコピペする。ARNをメモっておく。arn:aws:iam::(数字):role/(Role名)5.ブラウザ上でDynamoDBに接続するアプリケーションを作成するGoogleから取得する必要があるのは、id_tokenというJWTっていうJSONの情報をまとめて署名してるナニ(よく知らない)と、Googleのuser_idの二つ。id_tokenはGoogleのエンドポイントに渡すとそのトークンがどのアプリケーションIDに対して発行されたものかとか、どのuser_idに対するものであるとか、有効期限はいつまでだとか分かるのでその辺で有効な認証情報かAWS側で照合するのに利用されてるっぽい。user_idはDynamoDBに格納するときのキーとして使うことになる。これまでの手順が間違いなく出来ていたなら、DynamoDBにはこのid_tokenで確認されたuser_id以外のキーを受け入れないようになっている。APIのJavaScriptライブラリを使う方法がある。内部的には同じ手順を踏んでるはず。IDと、ユーザーにどこまでの権限を要求するかということを決めるscopeというものを用意する必要がある。ここではユーザーの基本的な情報(ユーザーIDの番号とアカウント)だけを要求する最低限のものにする。その場合以下のようなアドレスをscopeに設定する。https://www.googleapis.com/auth/userinfo.profile各scopeの要求時に表示される画面なんかは以下のアドレスで確認できる。Playgroundちなみに上記のサイトはGoogle認証のOAuth2.0の手順を追っかけられるサイトなので、何が起きてるのかとか全く分からないなら色々いじくり回すと良いと思う。話を戻して認証にはGoogle+ボタンを使う場合と直接やる場合とある。v1のloginを要求する権限が要求されてしまう。Google+を利用したことがないので分からないが、たぶんtwitterで言うと[今何々をプレイしてます!]みたいなものを自動でつぶやかせるために使うような権限だろうと思う。facebookで言うとウォールに載るかどうかみたいなもんだろう(facebookも使ったことがないのでこのたとえが正しいのかも知らない)scopeで言うと、https://www.googleapis.com/auth/plus.loginのやつがそれだ。+ボタンって言ってるんだし、たぶんもともとそういうもんなんだろう。上のuserinfo.profileで要求すると、+内でのユーザー情報と、+のサークルに知らせる権限と、Googleの情報とかなるので要求が多くて敬遠されそうな感じがする。あとログイン済みの場合、勝手に画面にトーストを表示させるを消す方法も分からなくて嫌だったので使わなかった。Google+のユーザーでその方面で共有して欲しいと思うなら、使い方は簡単なのでおすすめだ。GoogleがホストしてるJavaScriptのファイルをロードして、spanに決まったクラスやdata属性でアプリケーション情報なんかを設定するだけでid_tokenを含んだデータがcallbackに帰ってくる。以下に日本語で公式ドキュメントがあるので読めばすぐに使える。Developersuser_idに関しては、手順が共通なのでライブラリを直接操作してid_tokenを取得する方法のあとに書く。Google+ボタンを使わない方法というわけでライブラリの使い方。ちなみに+ボタンを使わないときでも、Google+ボタンガイドラインみたいなものがあって、それに準拠しなきゃならないのか悩むところだけど、何度か読み返してもこれはGoogle+の連携アプリとして作成するときはっつう話っぽいので多分大丈夫だと思う。+の権限を使うなら遵守すべき。Developersこのあたりのリファレンス読めば分かる(おわり)。一応ひっかかるポイントもあるのでサンプル。id_token"という風にid_tokenとtokenのどっちも指定すること。tokenはあとでuser_idを問い合わせるときに使う(たぶんid_tokenで問い合わせることも出来ると思うんだけど調べてない)。ちなみに指定しないとtokenになるみたいでid_tokenが取得できず悩んだ。immediateは連携許可の画面を出すか否かというフラグで、falseの場合、連携の有無に関係なく連携許可の画面がポップアップする。連携の許可があった場合、ポップアップはちらりと見えてすぐ消える。上記のログインできたときの処理が流れる。許可が無ければ、あるいはログインしていなければその画面内でログイン|承認を受けられればログインできたときの処理が流れる。trueの場合、連携の有無に関係なく、ポップアップは表示されない。連携がありログインしていれば問答無用でログイン処理に移行し、そうでなければできなかったときの処理が行われる。ログインの処理をまっとうにやろうとすると、gapi.auth.authorizeはimmediateフラグをtrueで流したのち、ログインできなかったらfalseで流し直すか、ログインボタンを表示して押されたらfalseで実行するような形にすべきなのだと思う。すると認証済みユーザーはシームレスに、新規ユーザーは承認画面に移行できる。user_idを取得するで、上記のどちらかの方法でid_tokenとaccess_tokenを取得できたはずだ。そもそもこのtokenって何のtokenかというと連携許可を受けたデータにアクセスするためのtokenなので、このtokenを自分が許可を受けた権限で要求可能なエンドポイントに投げてやれば必要な情報が手に入る(必要な操作を行える)という寸法である。これも上記のリファレンスに載っているのだけど、サンプルはこんな感じ。Browserざっと読めばだいたい大丈夫。https://sdk.amazonaws.com/js/aws-sdk-2.0.0-rc1.min.jsがsdkなのでscriptタグでロードしてやる。そいでサンプルはこんな感じ。//データに取り出した値が入る});AWS.configに設定しておくとS3とかDynamoDBとかで共通のリージョンとか認証情報が使える感じ。RoleArnにRoleを作ったときにメモっておいたArnを入れて、id_tokenを渡して、regionを設定すればあとはテーブルを操作するだけ。ItemとかKeyでDynamoDB側に値を渡しているときのSとかいう名前のプロパティはその値の型名でSはString、NはNumberとかそんな感じ。PLUGSという耳栓を海外から買った。