В 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 из обычного источника учётных данных. Этот фрагмент строит спецификацию запроса; вызывайте нужный URL API через request, используя обычный код запроса и проверки в тесте.

Схема http описывает конечную точку прокси. URL API может оставаться HTTPS. Механизм withAuth в REST Assured обеспечивает базовую аутентификацию прокси; он не согласует все корпоративные схемы аутентификации только потому, что были переданы две строки.

Помещайте учётные данные API в собственную конфигурацию аутентификации API. Не заменяйте учётную запись прокси общим заголовком Authorization или паролем службы. При HTTPS аутентификация на посреднике может потребоваться при установлении CONNECT, до того как возникнет HTTP-обмен с пунктом назначения.

Когда оставшаяся ошибка — доверие к сертификату

Отклонённый вызов CONNECT и ошибка проверки сертификата TLS — разные результаты. Если нужный сертификат CA, управляемый организацией, отсутствует в настройках доверия клиента, получите его по утверждённому административному каналу и настройте truststore тестового клиента.

REST Assured предоставляет для этого trustStore. Truststore меняет, каким издателям доверяет HTTPS-клиент; он не выбирает прокси и не передаёт его логин. Оставьте проверку имени хоста и сертификата включённой вместо использования accept-all рукопожатия, которое принимает любой предъявленный сертификат.

Похожие статьи