プロンプトとコンテキスト
ホテルや空港のネットワークを利用しているユーザーが、API から 511 Network Authentication Required を受信しました。ある担当者がそれを 401 や 302 に変更したため、SDK のリトライ、キャッシュ、ログインフローの間で競合が発生しています。511 の責任境界を説明し、401 および 407 と区別した上で、ブラウザ、モバイルクライアント、非ブラウザクライアント向けの安全なリカバリを設計してください。
この質問は、バックエンド、ネットワーク、プラットフォームの一般的な面接に適しています。重要なのは、ネットワーク接続許可とアプリケーションアカウント認証を混同せず、インターセプトプロキシを正しく特定することです。
面接官がテストしていること
優れた回答では、511 が通常ネットワークアクセスを制御するインターセプトプロキシによって生成され、クライアントがネットワーク接続許可を完了する必要があることを意味すると説明します。401 はオリジンまたは保護されたリソースがアプリケーション認証を要求していることを意味し、407 はプロキシがプロキシ資格情報を要求していることを意味します。また、511 はアプリケーションログインの証明ではなく、API クライアントが HTML リダイレクトを盲目的に JSON として扱ってはならないことも明記します。
最初に確認すべき明確化のための質問
- どのホップが 511 を生成したか、またクライアントはローカルプロキシとオリジンを区別できるか？
- クライアントはブラウザページ、ネイティブモバイルアプリ、CLI、バックグラウンドサービスのいずれであるか？
- ネットワークポータルには安定した検知エンドポイントと応答プロトコルが存在するか？
- API リクエストはリトライ可能か、またクライアントはネットワーク接続が許可されたことをどのように知るのか？
- TLS インターセプト、証明書ピニング、プロキシ資格情報、または機密シークレットは関係しているか？
30秒の回答フレームワーク
「511 はネットワーク接続許可レイヤーが認証を必要としていることを意味し、通常はインターセプトプロキシによって生成されます。401 はリソース認証、407 はプロキシ認証です。私なら 511 を 302 に変換したり、SDK にポータルの HTML を JSON としてパースさせたりはしません。ブラウザであれば制御されたネットワークログインプロンプトを表示できます。非ブラウザクライアントは構造化されたネットワーク状態を返し、盲目的なリトライを停止して、信頼できる確認が取れた後にのみ元のリクエストを再送信すべきです。アプリケーションの資格情報を未知のポータルに送信してはなりません。」
ステップごとの詳細な回答
ステップ 1: 511 を生成したエンティティを特定する
RFC 6585 は、ネットワークアクセスを取得するために認証が必要なクライアント向けに 511 を定義しており、MDN はこれがオリジンではなくインターセプトプロキシによって生成されると述べています。一般的な事例には、公衆 Wi-Fi の利用規約への同意、ポータルログイン、デバイス登録が含まれます。可能な限りプロキシおよびネットワークコンテキストをログに記録しますが、クライアントが常に仲介者を確実に識別できるとは想定しないでください。
ステップ 2: 401 との区別
401 は、ターゲットリソースに対する有効な資格情報がリクエストに不足していることを意味し、通常はオリジンの WWW-Authenticate チャレンジを伴います。クライアントはトークンをリフレッシュするか、アプリケーションプロトコルに従ってユーザーにサインインを促します。これはリソースの権限に関する問題を示しており、ローカルネットワークがまだ接続許可されていない状態とは異なります。
ステップ 3: 407 との区別
407 は Proxy-Authenticate および Proxy-Authorization を使用してプロキシ認証を要求します。プロキシ資格情報とアプリケーションアカウントの資格情報は異なる信頼ドメインに属します。407 を 401 として扱ったり、ユーザーのアプリケーションパスワードをプロキシヘッダーに入れたりしてはなりません。企業ネットワークおよび公衆ネットワークの資格情報ストレージには個別のポリシーが必要です。
ステップ 4: なぜ直接 302 を返してはならないのか？
302 はクライアントを別の URL に誘導します。ブラウザはそれに従うかもしれませんが、API SDK、Webhook コンシューマー、またはキャッシュがポータルの HTML をビジネスレスポンスとして処理してしまう可能性があります。クロスオリジンのポータルでは、リクエストコンテキストが漏洩するリスクもあります。ブラウザポータルが必要な場合は、すべての API レスポンスを暗黙的にリダイレクトさせるのではなく、制御されたナビゲーションフローでポータルを開き、完了後に元のリソースをリトライします。
ステップ 5: ブラウザ向けの処理を設計する
ブラウザは、ポータルリンクとリトライアクションを含む明確なネットワークログインプロンプトを表示できます。ポータルはアプリケーションのパスワードを要求したり、信頼されていないプロキシに OAuth コールバックトークンを公開したりしてはなりません。ログイン完了後、信頼できる検知リクエストを通じてネットワークアクセスを確認し、元のページを再読み込みします。
ステップ 6: 非ブラウザ向けの処理を設計する
モバイル、CLI、バックグラウンドクライアントは 511 を認識し、接続許可状態を記録して、指数関数的リトライを停止すべきです。これらは信頼できるネットワーク検知インターフェースを呼び出すか、システムネットワークレイヤーに委任できます。確認後、冪等なセマンティクスでリクエストを再送信します。リトライ不可能な書き込み処理については、ポータル認証が完了していない間の重複送信を防止します。
ステップ 7: TLS とセキュリティ境界を処理する
HTTPS において、デバイスや企業が信頼できるインターセプト証明書をインストールしていない限り、インターセプトプロキシは通常オリジンのコンテンツを安全に偽装することはできません。クライアントは「自動ログイン」のために証明書の検証を無効にしてはなりません。ポータル URL、証明書、およびリダイレクトポリシーには、特にセッション、決済、管理 API においてプロダクトおよびセキュリティレビューが必要です。
ステップ 8: 検証、モニタリング、リカバリ
実際の公衆ネットワークおよびシミュレートされたプロキシ上で、ブラウザ、ネイティブクライアント、CLI、バックグラウンドジョブ、キャッシュ、リトライをテストします。511 の発生率、ネットワークリージョン、ポータル完了率、リカバリ後の初回リクエスト成功率、重複書き込みを追跡します。401 および 407 が引き続き自身のコントラクトに従っていること、および 511 が長期間有効なエラーページとしてキャッシュされないことを検証します。
トレードオフと境界
511 は、ブロックがオリジンアカウントではなくネットワーク接続許可によるものであることをクライアントに伝えますが、仲介環境は常に観察可能である、または信頼できるとは限りません。これを本人確認の証跡としてではなく、リカバリのためのシグナルとして扱ってください。API においては、未知のページを自動的に開くよりも、安定したエラー構造を返してリトライを停止する方が安全です。
すべてのアクセス失敗を 511 にマッピングしないでください。オリジンログインには 401、プロキシ資格情報には 407、レート制限には 429 を使用し、ネットワーク接続が失敗した場合は HTTP レスポンスがまったく生成されないこともあります。ステータスは、実際に生成されたレイヤーとリカバリアクションを反映していなければなりません。
ロールアウト計画とエビデンス
まずテストネットワーク上で 511 ヘッダー、ボディ、キャッシュの動作、および生成プロキシを検証します。次に、クライアントの状態遷移（検知、通知、接続許可待ち、リトライ、失敗レポート）を定義します。ブラウザは制御されたポータルを使用し、非ブラウザクライアントはシステムネットワークレイヤーまたは運用に委任し、アプリケーションの資格情報をポータルページに渡すことは決してありません。
ネットワーク、クライアントバージョン、リクエストメソッドごとのダッシュボードとサンプリングされたログを構築します。書き込みには冪等性キーまたは明示的なリトライ不可コントラクトを追加し、リカバリ後に読み取りリクエストを再取得します。ポータルベンダーやプロキシポリシーが変更されたときは、必ず受け入れテストスイート全体を実行します。
よくある落とし穴とフォローアップ
511 を 401 として扱う
511 はネットワーク接続許可の問題であり、401 はリソース認証の問題です。それらのチャレンジヘッダー、資格情報、およびリカバリフローは異なる信頼ドメインに属します。
SDK に 302 を自動追従させる
ポータルの HTML が JSON としてパースされたりキャッシュされたりする可能性があります。まずネットワーク状態を検知し、制御されたフローでポータルログインを完了させます。
アプリケーションのパスワードをポータルに送信する
公衆ネットワークのプロキシにアプリケーションの資格情報を受信させてはなりません。ポータルはネットワークを接続許可するものであり、アプリケーション認証は依然としてオリジンのプロトコルです。
511 を無制限にリトライする
接続許可前のリトライはトラフィックを増幅させ、書き込みの重複を招く可能性があります。リトライを一時停止し、信頼できる接続許可を待ってから、冪等なセマンティクスを使用してください。
非ブラウザクライアントをどのようにテストしますか？
シミュレートされた環境および実際の公衆ネットワーク上で、CLI、モバイル、バックグラウンドジョブ、キャッシュ、およびリカバリ後の読み取り/書き込みをカバーします。511 の認識、リトライ停止、ポータル完了、および重複送信メトリクスを確認します。