Chrome onAuthRequired: 認証情報を送る前に isProxy を確認する

ブラウザ拡張は、リクエストを運ぶプロキシと宛先のウェブサイトという 2 つの異なる場所から認証チャレンジを受けることがあります。両者が自動的に同じアカウントを受け取ってはいけません。

Chrome の webRequest.onAuthRequired イベントで有用な判別子は isProxy です。プロンプトを消すためだけにこのチェックを外すコールバックは、オリジンのチャレンジにプロキシの認証情報を渡し始める可能性があります。

信頼しようとしているプロキシに一致させる

isProxy を確認することは出発点です。さらに、処理を想定したプロキシのチャレンジャーとリクエストの文脈に限定します。複数のエンドポイントを管理する拡張は、すべてのチャレンジに 1 つのグローバルなパスワードではなく、そのエンドポイントに属するアカウントを選ぶべきです。

プロキシのルートを設定することと、そのログインを処理することが 1 つの権限や 1 つの API 呼び出しだと考えないでください。Chrome はそれらを別々に文書化しています。イベントデータと認証権限には現在の webRequest リファレンスを使用します。Manifest V3 のリスナー登録の例 は、コールバック内での同期的な登録とアカウント選択を示しています。

マニフェストの世代を確認する

実験的な WebRequest API に言及した例は、古い拡張リリースのものです。現在の権限要件は、拡張のマニフェストの世代と配備モデルによって異なります。特に、認証の処理には独自のサポートされた権限パスがあります。古いブロッキングリスナーの例だけでは、Manifest V3 拡張がそのまま実行できることを示すには不十分です。

正しいハンドラは、拒否された同じ認証情報を無限に再試行することも避けなければなりません。アカウントを渡した後に再びチャレンジが来た場合は、パスワードを永遠に再生する要求ではなく、調査すべき証拠として扱ってください。

認証情報は拡張の適切な保護された処理経路にとどめるべきです。PAC ファイルに公開したり、配布するサンプルにハードコードしたりしないでください。目的は範囲を狭く限定したプロキシログインであり、すべての認証チャレンジに同じ秘密で答えるブラウザ全体のルールではありません。