1つのページが読み込まれるだけで、プロキシのログインボックスが繰り返し表示される
1つのページで認証プロンプトが繰り返されるとき、失敗しているリソース要求とプロキシ経路を追跡します。
ページは1つだけの要求を出すわけではありません。最初のプロキシのログインボックスに答えると、スクリプト、画像、ライブ接続が別の経路を通り、別のチャレンジを受け取る可能性があります。
- 失敗しているリソースを見つけます。 その宛先、選択されたプロキシ、407 チャレンジを記録します。同じ項目を成功しているリソースと比較してください。メインページの URL だけでは不十分です。
- 共通する違いを探します。 失敗は、1つのリソースホスト、別々の HTTP/HTTPS 経路、拡張機能、あるいは PAC の判断に沿って起きることがあります。あるエンドポイントで受け入れられたログインは、別のエンドポイントでも受け入れられることを証明しません。認証のキャッシュもチャレンジ、ID、経路のスコープに依存します。
- 特定したやり取りを修復します。 経路、アカウント、または対応している認証動作を修正し、そのうえでページの動作とリソースの結果の両方を確認します。
同じパスワードを何度も入力しても、そのスコープが分かるまではほとんど証拠になりません。WebSockets を無効にしたり、スクリプトをブロックしたり、拡張機能を変えたりする初期のブラウザ回避策は、ボックスを引き起こす要求を取り除くと同時に、必要な機能も取り除くことがあります。
不要なリソースをブロックすることは、意図的なポリシー上の選択になり得ます。その結果は、認証が機能するようになった証拠ではなく、ブロックとして説明してください。必要なリアルタイム接続を欠いた静かなページは、想定された経路を使う正常なページと同じ結果には達していません。