Azure Storage Java: API とトークン要求のプロキシ経路
Java SDK のプロキシを設定するときは、Azure Storage の要求と資格情報トークンの要求の両方を確認します。
ストレージ クライアントの HTTP トランスポートにプロキシを設定しても答えるのは 1 つの問いだけです。そのトランスポートがストレージ要求をどう送るか、という問いです。ID 資格情報はトークンの取得に別の HTTP クライアントを使う場合があります。
この違いは、よくあるように見える矛盾を説明します。ストレージ エンドポイントにはプロキシ経由で到達できるのに、SDK が想定された操作を送る前に失敗する、というものです。その失敗は ID エンドポイントに対する資格情報の取得に属する場合があります。
まずどの宛先が失敗したかを記録します。次に、ストレージ ビルダーに渡した HTTP クライアントと、資格情報の実装が使う構成を調べます。各トランスポートがサポートするプロキシ オプションに従います。許可された公開プロキシ経路で公開到達可能なストレージ エンドポイントとトークン エンドポイントには、HTTP プロキシ一覧が候補を提供します。1 つのビルダーの設定がアプリケーション内のすべてのオブジェクトを再構成すると考えないでください。
| 段階 | 有用な証拠 |
|---|---|
| トークンの取得 | ID エンドポイント、選択されたクライアント、プロキシのチャレンジまたは接続エラー |
| ストレージ要求 | ストレージ エンドポイント、構成されたパイプライン、最終応答または転送の失敗 |
プロキシ アカウントは Azure 資格情報と分けておきます。プロキシへのログインが成功すると経路が与えられますが、宛先サービスは依然として Azure 操作を認可します。
過去の回答には、古い OperationContext やパイプライン API を含む複数世代の Azure Storage Java クラスが使われています。例は、アプリケーションが現在使っている SDK と HTTP トランスポートに合わせてください。Data Lake SDK については、ストレージと ID の共有 HTTP クライアント設定がビルダーの 2 つの入力を示しています。プロキシの問題を解決するために廃止されたクライアント型を再導入すると、デバッグすべき構成経路がもう 1 つ増えます。
ログには安全なエンドポイント識別子を使います。ストレージ URL にはアクセス トークンが、完全なプロキシ URL にはパスワードが含まれる場合があります。