Базова автентифікація проксі для запиту 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 зі свого звичайного джерела облікових даних. Цей фрагмент будує специфікацію запиту; викликайте потрібну 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 рукостискання, яке приймає будь-який пред'явлений сертифікат.

Схожі статті