Podstawowe uwierzytelnianie serwera proxy dla żądania REST Assured

Użyj ProxySpecification dla adresu i konta pośrednika, a konfigurację zaufania pozostaw po stronie klienta HTTPS.

REST Assured ma specyfikację proxy, która przenosi razem adres i dane uwierzytelniające pośrednika:

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);

Aplikacja dostarcza proxyUser i proxyPassword ze swojego zwykłego źródła danych uwierzytelniających. Fragment buduje specyfikację żądania; wywołaj docelowy URL API przez request, używając zwykłego kodu żądania i sprawdzeń w teście.

Schemat http opisuje punkt końcowy proxy. URL API może pozostać HTTPS. Mechanizm withAuth w REST Assured zapewnia podstawowe uwierzytelnianie proxy; nie negocjuje każdego firmowego schematu uwierzytelniania tylko dlatego, że podano dwa ciągi znaków.

Umieść dane uwierzytelniające API w konfiguracji uwierzytelniania samego API. Unikaj zastępowania konta proxy ogólnym nagłówkiem Authorization lub hasłem usługi. W HTTPS uwierzytelnianie wobec pośrednika może być potrzebne podczas ustanawiania CONNECT, zanim istnieje wymiana HTTP z miejscem docelowym.

Gdy pozostałym problemem jest zaufanie do certyfikatu

Odrzucone wyzwanie CONNECT i błąd weryfikacji certyfikatu TLS to różne wyniki. Jeśli wymagany, zarządzany przez organizację CA nie występuje w konfiguracji zaufania klienta, pozyskaj go zatwierdzonym kanałem administracyjnym i skonfiguruj truststore klienta testowego.

REST Assured udostępnia w tym celu trustStore. Truststore zmienia, którym wystawcom ufa klient HTTPS; nie wybiera proxy ani nie podaje jego danych logowania. Pozostaw włączoną weryfikację nazwy hosta i certyfikatu, zamiast używać uścisku accept-all, aby przyjąć dowolny przedstawiony certyfikat.

Powiązane artykuły