Grunnleggjande proxy-autentisering for ein REST Assured-førespurnad

Bruk ProxySpecification for adressa og kontoen til mellomleddet, og lat tillitskonfigurasjonen liggje hos HTTPS-klienten.

REST Assured har ein proxy-spesifikasjon som ber adressa og påloggingsdetaljane til mellomleddet saman:

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 frå si vanlege kjelde for påloggingsdetaljar. Fragmentet byggjer ein førespurnadsspesifikasjon; kall den tiltenkte API-URL-en gjennom request med den vanlege førespurnads- og kontrollkoden til testen.

http-skjemaet skildrar endepunktet til proxyen. API-URL-en kan halde fram som HTTPS. withAuth-mekanismen i REST Assured leverer grunnleggjande proxy-autentisering; han forhandlar ikkje om alle føretaksautentiseringsskjema berre fordi to strengar vart oppgjevne.

Set API-påloggingsdetaljane i den eigne autentiseringskonfigurasjonen til API-et. Unngå å bytte ut proxy-kontoen med ein generell Authorization-header eller eit tenestepassord. Ved HTTPS kan autentisering mot mellomleddet vere naudsynt medan CONNECT vert etablert, før HTTP-utvekslinga med målet finst.

Når den attverande feilen er sertifikattillit

Ei avvist CONNECT-utfordring og ein TLS-sertifikatvalideringsfeil er ulike resultat. Viss den påkravde organisasjonsstyrte CA-en manglar i tillitsoppsettet til klienten, skaff han gjennom den godkjende administrative kanalen og konfigurer truststore til testklienten.

REST Assured eksponerer trustStore for det føremålet. Eit truststore endrar kva utsendarar HTTPS-klienten stolar på; det vel ikkje proxyen og gjev ikkje pålogginga hans. Hald vertsnamn- og sertifikatvalidering på i staden for å bruke eit accept-all-handtrykk for å godta kva sertifikat som helst som vert lagt fram.

Relaterte artiklar