Grunnleggende proxy-autentisering for en REST Assured-forespørsel

Bruk ProxySpecification for mellomleddets adresse og konto, og la tillitskonfigurasjonen bli værende hos HTTPS-klienten.

REST Assured har en proxy-spesifikasjon som bærer mellomleddets adresse og påloggingsdetaljer sammen:

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

Applikasjonen leverer proxyUser og proxyPassword fra sin vanlige kilde for påloggingsdetaljer. Fragmentet bygger en forespørselsspesifikasjon; kall den tiltenkte API-URL-en gjennom request med testens vanlige forespørsels- og kontrollkode.

http-skjemaet beskriver proxy-endepunktet. API-URL-en kan forbli HTTPS. withAuth-mekanismen i REST Assured leverer grunnleggende proxy-autentisering; den forhandler ikke alle virksomheters autentiseringsskjemaer bare fordi to strenger ble oppgitt.

Plasser API-påloggingsdetaljer i API-ets egen autentiseringskonfigurasjon. Unngå å erstatte proxy-kontoen med en generell Authorization-header eller et tjenestepassord. Ved HTTPS kan autentisering mot mellomleddet være nødvendig mens CONNECT etableres, før HTTP-utvekslingen med målet finnes.

Når den gjenværende feilen er sertifikattillit

En avvist CONNECT-utfordring og en TLS-sertifikatvalideringsfeil er forskjellige resultater. Hvis den påkrevde organisasjonsstyrte CA-en mangler i klientens tillitsoppsett, skaff den gjennom den godkjente administrative kanalen og konfigurer testklientens truststore.

REST Assured eksponerer trustStore for det formålet. Et truststore endrer hvilke utstedere HTTPS-klienten stoler på; det velger ikke proxyen og gir ikke påloggingen dens. Hold vertsnavn- og sertifikatvalidering på i stedet for å bruke et accept-all-håndtrykk for å godta hvilket som helst sertifikat som presenteres.

Relaterte artikler