REST Assured besitzt eine Proxy-Spezifikation, die Adresse und Anmeldedaten des Vermittlers gemeinsam trägt:

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

Die Anwendung liefert proxyUser und proxyPassword aus ihrer üblichen Quelle für Anmeldedaten. Das Fragment baut eine Anfragespezifikation auf; rufen Sie die vorgesehene API-URL über request mit dem üblichen Anfrage- und Prüfcode des Tests auf.

Das Schema http beschreibt den Proxy-Endpunkt. Die API-URL kann HTTPS bleiben. Der withAuth-Mechanismus von REST Assured liefert die Basic-Proxy-Authentifizierung; er handelt nicht jedes Unternehmens-Authentifizierungsschema aus, nur weil zwei Zeichenketten übergeben wurden.

Legen Sie API-Anmeldedaten in der eigenen Authentifizierungskonfiguration der API ab. Vermeiden Sie es, das Proxy-Konto durch einen allgemeinen Authorization-Header oder ein Dienstpasswort zu ersetzen. Bei HTTPS kann die Authentifizierung am Vermittler nötig sein, während CONNECT aufgebaut wird, bevor der HTTP-Austausch mit dem Ziel überhaupt existiert.

Wenn der verbleibende Fehler das Zertifikatsvertrauen ist

Eine abgelehnte CONNECT-Aufforderung und ein TLS-Zertifikatsvalidierungsfehler sind unterschiedliche Ergebnisse. Fehlt die erforderliche, von der Organisation verwaltete CA in der Vertrauenskonfiguration des Clients, beschaffen Sie diese CA über den freigegebenen administrativen Weg und konfigurieren Sie den Truststore des Testclients.

REST Assured stellt dafür trustStore bereit. Ein Truststore ändert, welchen Ausstellern der HTTPS-Client vertraut; er wählt nicht den Proxy aus und liefert nicht dessen Anmeldung. Lassen Sie Hostnamen- und Zertifikatsprüfung aktiviert, statt einen accept-all-Handshake zu verwenden, der jedes vorgelegte Zertifikat annimmt.

Ähnliche Artikel