2

ゲーム用の RESTful API を作成しようとしています。

このゲームは、匿名ユーザー (今すぐプレイしたいユーザー) と登録したいユーザーの両方をサポートします。

私が達成しようとしているのは、未登録のユーザーがまだ同じコンピューターを使用している間、それらに関連付けられたデータが永続化されることです。登録することを選択した人に対する適切なユーザーサポートもあり、うまくかみ合わせるのに苦労しています.

GET users/create Users.create ユーザーを返す新しい「匿名」ユーザーを作成します(およびそれによって識別できる一意のトークン)

POST users/register Users.register オプションのトークン (ユーザーが以前に匿名だった場合)、電子メール、およびパスワードを受け取ります。新しい登録ユーザーが作成されます (トークンが提供されている場合は同じトークンを使用するか、新しいユーザーが作成されます)。

POST auth/login Auth.login メールアドレスとパスワードを取得し、成功した場合はユーザーを返します

POST auth/authenticate一意のトークンを受け取り、データベースにトークンが存在するかどうかに基づいて 200/500 を返します。

基本的に、サーバーへのすべての呼び出しには、これらの一意のトークンのいずれかが必要です。それを使用して、関連付けられているユーザーを追跡できます。

登録ユーザー向けにある種の「remember me」機能を実装しようとすると、本当に混乱します。登録ユーザーがこれらの一意のトークンのいずれかを使用できる場合、それを記憶トークンとして使用できますか? これは、セキュリティ上、不適切な選択であり、多くのauth/authenticate失敗を引き起こす可能性があるようです。ユーザーが新しいコンピューターにログインするたびに、新しいトークンを作成する必要があるためです。

私は何かを完全に見逃していますか?このプロセス全体には、セキュリティ災害があちこちに書かれているようです。この種の行動のための良いレシピはありますか?

乾杯、

イアン

4

2 に答える 2

2

トークン (ブラウザーに保存された Cookie の一意の識別子) は、Play がステートレスであることを考慮してユーザーを一意に識別するために使用できる (私が認識している) 唯一の方法です。

重要なのは、リクエストのパラメーターとしてトークンを送信するのではなく、リクエストごとに Cookie (再生セッション) からトークンを直接取得することです。

安全性については、比較的安全なはずです。Play の Cookie は暗号で保護されているため、変更や偽造はできません。上に SSL を追加すると、盗聴されないため、別のユーザーを「偽装」することはできません。これをさらに強化するには、UUID を使用します (有効なトークンを生成するのが難しくなります)。

実際、Play で「セッション」を行う唯一の方法は、ユーザー ID (または何らかの識別子) をアプリケーションの Cookie に保存することです。これは、基本的にやりたいことです。

ああ、Brian Kelly が指摘したように、GET を使用してユーザーを作成しないでください。

于 2011-10-19T08:19:26.993 に答える
1

プレイセキュリティガイドを確認しましたか?特にクロスサイトリクエストフォージェリの部分。
Play はcheckAuthenticity()メソッドを使用して、すべての投稿リクエストの信頼性を検証します。フォームに認証トークンを含む#{form}タグ
を必ず使用してください。または、通常の HTML フォーム タグで#{authenticityToken /}タグを使用します。

于 2011-10-19T11:01:50.093 に答える