Web サイトで .htaccess 認証を使用しています。AD vi LDAP で認証が行われると、認証されたユーザーのセッションと Cookie がブラウザーでどのように作成されたか、およびリダイレクトが実際に私の Web サイトで行われている場所です。これを手伝うか、このプロセスを説明するリンクを共有してください。
1 に答える
BASIC 認証とDIGEST 認証の wiki ページを見てください。どちらもプロトコル (HTTP) 上の認証メカニズムです。基本的に、これはブラウザーが見るものです (ここではかなり言い換えています):
- URI を要求しようとすると、Web サーバーは 401 応答と
WWW-Authenticate
ヘッダーで応答します - このヘッダーには REALM が含まれています。これは、すべてが同じ認証レルムに属するページのグループのようなものです。
- ブラウザは、ユーザー名とパスワードを求めるモーダル ダイアログ ボックスを表示します。
- BASIC または DIGEST に応じて、そのパスワードは 401 になった元の要求と共に Web サーバーに送り返されます。
- 資格情報が正しくない場合は、403 が返され、ブラウザーに適切なエラー メッセージが表示されます。それ以外の場合、Web サーバーは要求されたページを返します。
- ブラウザーは、この URL が REALM に属していることを認識しているため、この URL が要求されるたびに、承認が要求と共に自動的に送信されます。
- ブラウザーが認証を必要とする別のものを要求し、それが同じ REALM に属している場合、Web サーバーが 401 と REALM を返すと、ブラウザーは自動的に承認を送信します。
REALM 情報と資格情報のリストを使用して Web サーバーを構成する方法はさまざまです。LDAP データベース、アクティブ ディレクトリ、ハッシュ化されたパスワードを含むフラット ファイルなどに接続できます。
これは、認証に HTTP プロトコルを使用しないため、Cookie やその他の webapp レベルの認証とは異なります。webapp には、ユーザー名とパスワードのフォームを含むページがあり、それらはパラメーターとして POST/GET 要求を介して送信され、それらの資格情報が有効かどうかを判断するのは webapp 次第です。それらが有効な場合、webapp はセッション ID を Cookie として保存することを選択できるため、ブラウザーは webapp によって提供されるページを引き続き参照できます。
この認証と HTTP 認証のエンド ユーザーの違いの 1 つは、Web アプリケーションが Cookie を削除したり、そのセッションを無効にしたりして、基本的に Web アプリケーションからユーザーをログアウトできることです。これは、HTTP 認証では実際には不可能です。ブラウザーは、同じ REALM でページを要求するときに、やみくもに認証ヘッダーを送信するからです。これを回避する 1 つの方法は、保護されたページが要求されたときに Web サーバーが強制的に 403 を返すようにすることです。
もう 1 つの違いは、HTTP 認証では、URL の一部としてユーザー名/パスワードを含めることができることです。http://user:pass@host.com 認証はどのように機能しますか?
一般的な認証のより完全な説明については、 http: //blog.distributedmatter.net/post/2008/06/09/HTTP-authentication-mechanisms-and-how-they-could-work-in-Restletも参照してください。