REST Assured heeft een proxyspecificatie die het adres en de inloggegevens van de tussenpersoon samen draagt:

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

De applicatie levert proxyUser en proxyPassword uit haar gebruikelijke bron van inloggegevens. Het fragment bouwt een verzoekspecificatie op; roep de bedoelde API-URL aan via request met de gebruikelijke aanvraag- en controlecode van de test.

Het http-schema beschrijft het eindpunt van de proxy. De API-URL kan HTTPS blijven. Het withAuth-mechanisme van REST Assured levert basisproxy-authenticatie; het onderhandelt niet over elk bedrijfsauthenticatieschema alleen omdat er twee tekenreeksen zijn opgegeven.

Plaats API-inloggegevens in de eigen authenticatieconfiguratie van de API. Vermijd het vervangen van het proxyaccount door een algemene Authorization-header of een servicewachtwoord. Bij HTTPS kan authenticatie bij de tussenpersoon nodig zijn tijdens het opzetten van CONNECT, voordat de HTTP-uitwisseling met de bestemming bestaat.

Wanneer de resterende fout certificaatvertrouwen is

Een geweigerde CONNECT-uitdaging en een TLS-certificaatvalidatiefout zijn verschillende uitkomsten. Als de vereiste, door de organisatie beheerde CA ontbreekt in de vertrouwensregeling van de client, verkrijg die CA dan via het goedgekeurde administratieve kanaal en configureer de truststore van de testclient.

REST Assured stelt trustStore voor dat doel beschikbaar. Een truststore verandert welke uitgevers de HTTPS-client vertrouwt; hij kiest de proxy niet en levert de aanmelding ervan niet. Houd hostnaam- en certificaatvalidatie ingeschakeld in plaats van een accept-all-handshake te gebruiken om welk certificaat dan ook te accepteren.

Gerelateerde artikelen