2

REST (HTTP) [JSON] 経由でサーバーと通信する JavaScript クライアントを使用してシステムを作成しています。

役割ベースのアクセス制御を使用して通話を管理しています。

例: [明示的な URL は変更されません]

  • 匿名 -> リクエスト\
  • サーバー -> ログインフォームへのルーティング:\login\
  • ユーザー (現在は Cookie 付き!) -> リクエスト\
    • if (user->role == "manager") return "\manager-homepage\";
    • else return "\homepage\";

REST はステートレスなので、このユースケースをどのように管理すればよいでしょうか?

リクエストごとに Cookie を送信すると、返された HTTP ステータス コードによって JS にルーティング先が通知されますか?

[どちらかというと非効率的 + MITM 攻撃を受けやすい]

4

1 に答える 1

1

http ダイジェストなどの標準的な認証スキームを使用できませんか?

例：[ウィキペディアのページから]

  • クライアントは、認証が必要なページを要求しますが、ユーザー名とパスワードを提供しません。これは通常、ユーザーが単にアドレスを入力したか、ページへのリンクをたどったためです。
  • サーバーは 401 "client-error" 応答コードで応答し、認証レルムと、ノンスと呼ばれるランダムに生成された使い捨ての値を提供します。
  • この時点で、ブラウザーは認証領域 (通常、アクセスされているコンピューターまたはシステムの説明) をユーザーに提示し、ユーザー名とパスワードの入力を求めます。ユーザーは、この時点でキャンセルすることを決定できます。
  • ユーザー名とパスワードが提供されると、クライアントは同じ要求を再送信しますが、応答コードを含む認証ヘッダーを追加します。
  • この例では、サーバーが認証を受け入れ、ページが返されます。ユーザー名が無効であるか、パスワードが正しくない場合、サーバーは「401」応答コードを返す可能性があり、クライアントはユーザーに再度プロンプトを表示します。

注: クライアントは、必要なユーザー名とパスワードを既に持っている場合があります。ユーザーにプロンプ​​トを表示する必要はありません (以前に Web ブラウザーによって保存されている場合など)。

非常によく似た質問に対するこの回答も参照してください: REST and authentication variants

希望するセキュリティ レベルに応じて、ssl 経由ですべてを提供できます。これにより、ミット攻撃を防ぐことができます。

于 2012-06-23T08:33:34.977 に答える