Grundläggande proxyautentisering för en REST Assured-begäran

Använd ProxySpecification för förmedlarens adress och konto och låt förtroendekonfigurationen ligga hos HTTPS-klienten.

REST Assured har en proxyspecifikation som bär förmedlarens adress och inloggningsuppgifter tillsammans:

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

Programmet levererar proxyUser och proxyPassword från sin vanliga källa för inloggningsuppgifter. Fragmentet bygger en begäransspecifikation; anropa den avsedda API-URL:en via request med testets vanliga begärans- och kontrollkod.

http-schemat beskriver proxyns slutpunkt. API-URL:en kan förbli HTTPS. REST Assureds withAuth-mekanism ger grundläggande proxyautentisering; den förhandlar inte fram alla företagsautentiseringsscheman bara för att två strängar angavs.

Placera API-inloggningsuppgifter i API:ets egen autentiseringskonfiguration. Undvik att ersätta proxykontot med en allmän Authorization-rubrik eller ett tjänstelösenord. Vid HTTPS kan autentisering mot förmedlaren behövas när CONNECT upprättas, innan HTTP-utbytet med målet finns.

När det återstående felet är certifikatförtroende

En avvisad CONNECT-utmaning och ett TLS-certifikatvalideringsfel är olika resultat. Om det krävda organisationsstyrda CA:et saknas i klientens förtroendeuppsättning, skaffa det via den godkända administrativa kanalen och konfigurera testklientens truststore.

REST Assured exponerar trustStore för det ändamålet. Ett truststore ändrar vilka utfärdare HTTPS-klienten litar på; det väljer inte proxyn och tillhandahåller inte dess inloggning. Låt värdnamns- och certifikatvalidering vara på i stället för att använda ett accept-all-handskak för att ta emot vilket certifikat som helst som presenteras.

Relaterade artiklar