REST Assured リクエストのためのプロキシ基本認証
中継サーバーのアドレスとアカウントには ProxySpecification を使い、信頼の設定は HTTPS クライアント側に置いたままにします。
REST Assured には、中継サーバーのアドレスと資格情報をまとめて保持するプロキシ仕様があります:
import static io.restassured.RestAssured.given;
import io.restassured.specification.ProxySpecification;
var proxy = ProxySpecification.host("proxy.example")
.withPort(8080)
.withScheme("http")
.withAuth(proxyUser, proxyPassword);
var request = given().proxy(proxy);アプリケーションは通常の資格情報の取得元から proxyUser と proxyPassword を渡します。この断片はリクエスト仕様を組み立てるものです。テストの通常のリクエストと検証のコードを使い、request を通じて目的の API URL を呼び出します。
http スキームはプロキシのエンドポイントを表します。API の URL は HTTPS のままでかまいません。REST Assured の withAuth は基本プロキシ認証を提供しますが、文字列を 2 つ渡したというだけで、あらゆる企業向け認証方式を交渉するわけではありません。
API の資格情報は API 自身の認証設定に置いてください。プロキシのアカウントを汎用の Authorization ヘッダーやサービスのパスワードで代用しないでください。HTTPS では、宛先との HTTP 交換が存在する前に、CONNECT を確立する段階で中継サーバーへの認証が必要になることがあります。
残る失敗が証明書の信頼である場合
拒否された CONNECT チャレンジと TLS 証明書の検証エラー は別の結果です。組織が管理する必要な CA がクライアントの信頼設定にない場合は、承認された管理経路でその CA を入手し、テストクライアントの truststore を設定します。
REST Assured はそのために trustStore を公開しています。truststore は HTTPS クライアントがどの発行者を信頼するかを変えるもので、プロキシを選んだりそのログイン情報を与えたりはしません。提示された証明書をそのまま受け取る accept-all のハンドシェイクを使わず、ホスト名と証明書の検証を有効のままにしてください。