Grundlæggende proxy-godkendelse til en REST Assured-anmodning

Brug ProxySpecification til mellemledets adresse og konto, og lad tillidskonfigurationen blive på HTTPS-klienten.

REST Assured har en proxy-specifikation, som bærer mellemledets adresse og legitimationsoplysninger 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);

Applikationen leverer proxyUser og proxyPassword fra sin normale kilde til legitimationsoplysninger. Fragmentet opbygger en anmodningsspecifikation; kald den tilsigtede API-URL gennem request med testens normale anmodnings- og assertionskode.

http-skemaet beskriver proxy-endpointet. API-URL'en kan forblive HTTPS. REST Assureds withAuth-mekanisme leverer grundlæggende proxy-godkendelse; den forhandler ikke alle virksomheders godkendelsesskemaer, blot fordi der blev givet to strenge.

Anbring API-legitimationsoplysninger i API'ets egen godkendelseskonfiguration. Undgå at erstatte proxy-kontoen med en generel Authorization-header eller en tjenesteadgangskode. For HTTPS kan godkendelse over for mellemledet være nødvendig, mens CONNECT etableres, før der findes en HTTP-udveksling med destinationen.

Når den resterende fejl er certifikattillid

En afvist CONNECT-udfordring og en TLS-certifikatvalideringsfejl er forskellige resultater. Hvis den krævede organisationsstyrede CA mangler i klientens tillidsopsætning, skal du hente den CA via den godkendte administrative kanal og konfigurere testklientens truststore.

REST Assured eksponerer trustStore til det formål. En truststore ændrer, hvilke udstedere HTTPS-klienten stoler på; den vælger ikke proxyen og leverer ikke dens login. Lad værtsnavn- og certifikatvalidering være slået til i stedet for at bruge et accept-all-håndtryk til at samle op, hvilket certifikat der end præsenteres.

Relaterede artikler