こんにちは、この質問についてのこの観察と質問を以前にすでに書いていますが、後でそれが古くて「死んだ」質問であることに気づきました。他の人からの洞察が本当に欲しいので、私はそれを新しい質問として再投稿しています。
認証をRESTfulに行う方法については、一般的に「HTTP認証」と熱狂的に叫びます。しかし、それらの人々が（マシンツーマシンのWebサービスではなく）RESTを使用してブラウザーベースのアプリケーションを作成しようとしたことがあるかどうかは疑問です。（犯罪は意図されていません-私は彼らが合併症に直面したことはないと思います）
ブラウザで表示するHTMLページを生成するRESTfulサービスでHTTP認証を使用する際に私が見つけた問題は次のとおりです。
- ユーザーは通常、ブラウザで作成された醜いログインボックスを取得しますが、これはユーザーにとって使い勝手がよくありません。パスワードの取得、ヘルプボックスなどを追加することはできません。
- ログアウトまたは別の名前でログインするのは問題です-ウィンドウを閉じるまで、ブラウザは認証情報をサイトに送信し続けます
- タイムアウトは難しい
これらにポイントごとに取り組む非常に洞察に満ちた記事がここにありますが、これは多くのブラウザ固有のjavascriptハッカー、回避策の回避策などにつながります。そのため、上位互換性もありません。新しいブラウザがリリースされるたびに、定期的なメンテナンスが必要になります。クリーンでクリアなデザインだとは思いません。それに、RESTバッジを友達に熱心に見せるためだけに、余分な作業と頭痛の種がたくさんあると思います。
クッキーが解決策だと思います。しかし、待ってください、クッキーは邪悪ですよね？いいえ、そうではありません。Cookieの使用方法は悪です。Cookie自体は、ブラウザが閲覧中に追跡するHTTP認証情報と同様に、クライアント側の情報の一部にすぎません。また、このクライアント側の情報は、HTTP認証情報と同じように、要求ごとにサーバーに送信されます。概念的には、唯一の違いは、このクライアント側の状態の内容が、サーバーの応答の一部としてサーバーによって決定される可能性があることです。
次のルールだけでセッションをRESTfulリソースにすることによって：
- セッションは、キーをユーザーID（および場合によってはタイムアウトのlast-action-timestamp）にマップします
- セッションが存在する場合、それはキーが有効であることを意味します。
- ログインとは/sessionsにPOSTすることを意味し、新しいキーがCookieとして設定されます
- ログアウトとは、/ sessions / {key}を削除することを意味します（POSTがオーバーロードされている場合、私たちはブラウザであり、HTML 5はまだ長い道のりです）
- 認証は、リクエストごとにCookieとしてキーを送信し、セッションが存在して有効であるかどうかを確認することによって行われます。
HTTP認証との唯一の違いは、認証キーがサーバーによって生成され、クライアントが入力された資格情報から計算するのではなく、サーバーによって生成され、送信し続けるクライアントに送信されることです。
これは問題なく機能する十分なソリューションだと思いますが、このスキームの潜在的な穴を特定するのに十分なセキュリティの専門家ではないことを認めなければなりません-私が知っているのは、RESTfulではない何百ものWebアプリケーションが本質的に同じものを使用していることだけですログインプロトコル（$ _ SESSION inphp、j2eeのHttpSessionなど）。cookieヘッダーの内容は、accept-languageを使用して翻訳リソースなどにアクセスするのと同じように、サーバー側のリソースをアドレス指定するために使用されます。同じように感じますが、そうでない人もいるかもしれません。どう思いますか？