5

私はRESTfulサーブレットを作成しましたが、UI開発者はログイン状態をサーバーに保存したいと考えています。

彼はこの奇妙な主張をしました：「私は純粋なRESTである本番REST実装に遭遇していません。私が見たものはすべてサーバーにセッションを維持させました。」

これを受け入れるのは難しいと思います。まず、純粋にRESTfulなプレーンHTTPページがたくさんあるという技術があります。第二に、はい、「ゴールド」とラベル付けされた真ちゅうがあるのと同じように、RESTfulとラベル付けされた非RESTful実装があります。第三に、他のみんなが橋から飛び降りたからといって、私がそうすべきだという意味ではありません。

背景：HTTPSと基本認証を使用するJavaScriptAjaxWebアプリケーションです。通常の（カスタマイズできない）ブラウザログインポップアップボックスを回避するために、アプリケーションは、製品ロゴと名前とパスワードのテキストボックスを含むログイン画面を表示します。名前とパスワードはドキュメントに保存され、リクエストごとにAuthorizationヘッダーで送信されます。ページを更新すると、名前とパスワードが失われるため、ユーザーはそれらを再入力する必要があります。これはバグと見なされます。UI開発者は、パスワードを再度入力せずに更新ボタンを押すことができるようにしたいと考えています。

そのため、開発者はCookieまたはJSPセッションを使用したいと考えています。アビー、結局のところ、すべてのREST実装がサーバー上でアプリケーションの状態を維持しているというのは本当ですか？または、この問題を解決し、RESTfulな純度を維持する方法はありますか？

4

4 に答える 4

3

実用上の理由（主に閲覧可能な機能）のために、アプリケーションの状態と認証の状態を区別する必要があると思います。サーバー側で何らかの形の状態を保持しない認証メカニズムは考えられません。

本当に重要なのは、それがアプリケーションからどれだけ切り離されているかです。たとえば、HTTPダイジェストはサーバー上に何らかの形式の状態を保持しますが、これは通常WWW-AuthenticateのAuthorizationヘッダーネゴシエーションの一部として明確に抽象化されています。ほとんどのブラウザはネイティブでサポートしているため、これはアプリケーションと直交しており、RESTのステートレスの原則に違反することはありません。

現在、ユーザーはHTTP基本/ダイジェスト認証がブラウザーで満たされないという美的期待を持っているため、Webサイトはフォームベースの認証とそれに続くCookieを使用する傾向があります。公平を期すために、それは見た目だけでなく、使いやすさ（たとえば、「パスワードを忘れた」情報ですが、401応答の本文に含まれている可能性があります）とセキュリティの問題でもあります。ブラウザーでは、基本/ダイジェスト/証明書認証から簡単にログオフすることはできません。ただし、前述のように、完全にAjaxで単一ページ内で行われ、CSRFに役立つ場合を除きます。

認証にはCookieを使用できると思いますが、アプリケーション関連の変数をセッションに保存しないようにしてください。

このトピックに関するロイ・フィールディングのコメントのいくつかを読むことができます：

認証は直交しています。Cookieは、単にコンテンツのネゴシエーションまたは認証に使用される場合にも直交します。ただし、Cookie認証は可視性がないためRESTで許可されていません。これは、他のコンポーネントが機密情報であることを認識していないため、セキュリティ上の問題を引き起こします。

編集（セキュリティの側面に関するさらなるコメント）：

私が引用したメッセージのロイ・フィールディングのコメントは、セキュリティ上の理由からCookieに反対していることに気づきました。もちろん彼は正しい。ただし、私の意見では、Cookieの盗難よりも​​、Basic / Digest / Cert（2003年、そのメッセージの日付では実際には注目されていませんでした）を介してCSRFから保護することは困難です。もちろん実装にもよります。完璧な解決策はありませんが、Cookieを使用する場合は、HTTPS経由で安全なCookieを使用してください。

于 2010-06-25T16:16:17.467 に答える
2

クライアント側でこの情報を維持するためにCookieを使用しても問題はありません。Cookieが問題になるのは、サーバー側のセッション状態へのポインターとして使用された場合のみです。

あなたが心配しなければならない主なことは、クッキーの情報のセキュリティです。おそらく、Cookieにクリアテキストのパスワードを入れたくないでしょう:-)

于 2010-06-25T16:01:35.880 に答える
0
  • デフォルトでは、ページを更新するときにブラウザがクレンデンシャルを再度要求することはありません。これを修正すると問題が解決するため、これを調べることをお勧めします。
  • ユーザーがHTTPまたはCookieのいずれかで認証できることを除いて、ほとんどの部分でRESTサービスを維持できます。つまり、Cookieがない場合でもサービスは機能します。

よろしく、

アビー。

于 2010-06-25T16:03:14.547 に答える
0

認証後に何らかのセッションIDを返し、それを各呼び出しで渡す場合、これは実際には、各呼び出しで認証資格情報を渡すことと大差ありません。パフォーマンスに関しては、後者は引き続き資格情報をキャッシュできるため、パフォーマンスへの影響はありません。セキュリティの観点から、セッションは期限切れになりますが、クレデンシャルは（通常は）期限切れにならないため、クレデンシャルを保持する必要がない方が優れています。間違いなく、サーバーは呼び出し間のすべてを忘れることができますが、それでも機能するため、セッションの回避はより堅牢です。

要するに、どちらの方向にも圧倒的に強い議論はなく、RESTへの取り​​組みが十分に「純粋」であるかどうかにとらわれるべきではないでしょう。本当の問題はクライアントの振る舞いであり、Sjoerdが示唆しているように、これとは別に微調整することができます。

于 2010-06-25T16:09:39.620 に答える