2016-05-01 25 views
0
  • サーバはブラウザがinserのユーザー名とを自動的に パスワードと再送信要求を促すコード401
  • で を応答Xユーザーは、保護されたリソースを要求した後、サーバー これらの認証情報

私の質問は:保護されたリソースごとに繰り返しこのプロセスが繰り返されていますか? RFC 2617でHTTP基本認証メカニズム

+1

なぜそれを試してみませんか? – yaakov

+0

これは量子物理学ではないということです...どこかで文書化されるべきですが、どこで見つけることができませんか? – GionJh

+0

これは実装によって異なる場合があります(例:.NETの 'PreAuthenticate')。 – yaakov

答えて

1

ルック基本athenticationのためにそこに記載されている:

オリジンサーバがチャレンジで応答することができる 保護空間内のURIのための不正な要求を受けた...

と、クライアントが仮定すべきでも

その
の深さよりも深いか、すべてのパスRequest-URIのパスフィールドの最後の記号要素も
は、現在のチャレンジである の基本領域値で指定された保護領域内にあります。クライアントは
に対応する認証ヘッダーを先読みして、そのリソースの要求を
にして、サーバーから別のチャレンジを受信せずに送信してもよい(MAY)。
同様に、クライアントがプロキシに要求を送信すると、Proxy-Authorizationヘッダーフィールドに
のユーザーIDとパスワードを再利用することがあります。
はプロキシサーバーから別のチャレンジを受け取りません。

したがって、サーバー側からは、サーバーが認証されていないとみなす要求で発生することがあります。リソースYがリソースXとyuthenticatedされた接頭辞を共有しない場合、サーバーは認証を再要求します。

これを回避するために、認証方式、例えば、リソースXのプレフィックスに対する認証がプレフィックスとしてリソースYもカバーするように、関連リソースの共通プレフィックスに対する認証を要求することができる。これにより、クライアントは認証ヘッダーを送信し、サーバーはすでに認証されているものとしてコールを検出します。

+0

ちょうどいいです!ありがとう;) – GionJh

+0

RFC 2617は新しいRFCによって廃止されました(しかし、答えはまだ正しいです) –

0

ユーザーがパスワードを入力すると、ブラウザはそれを覚えています。 クライアントが同じWebサイトでリソースを要求するたびに、ブラウザは認証ヘッダーを自動的に送信します。