REST Assured huet eng Proxy-Spezifikatioun, déi d'Adress an d'Authentifikatiounsdonnéeë vum Vermëttler zesummen dréit:

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

D'Applikatioun liwwert proxyUser an proxyPassword aus hirer üblecher Quell vun Authentifikatiounsdonnéeën. De Fragment baut eng Ufro-Spezifikatioun; rufft déi ugeduecht API-URL iwwer request mat dem übleche Code fir Ufro an Assertioun vum Test op.

Den http-Schema beschreift den Endpunkt vum Proxy. D'API-URL ka HTTPS bleiwen. De withAuth-Mechanismus vu REST Assured liwwert Basis-Proxy-Authentifizéierung; hien handelt net all Firmen-Authentifizéierungsschema aus, just well zwou Zeecheketten uginn goufen.

Setzt d'API-Authentifikatiounsdonnéeën an d'eegen Authentifizéierungskonfiguratioun vun der API. Vermeit et, de Proxy-Kont duerch en allgemengen Authorization-Header oder en Déngschtpasswuert ze ersetzen. Bei HTTPS kann d'Authentifizéierung beim Vermëttler néideg sinn, wärend CONNECT opgebaut gëtt, ier den HTTP-Austausch mam Zil existéiert.

Wann de reschtleche Feeler d'Zertifikatsvertraue ass

Eng ofgelehnt CONNECT-Erausfuerderung an e Feeler bei der TLS-Zertifikatsvalidéierung sinn ënnerschiddlech Resultater. Wann déi erfuerdert, vun der Organisatioun verwalt CA an der Vertrauenskonfiguratioun vum Client feelt, beschaaft dës CA iwwer den approuvéierte administrativen Kanal a konfiguréiert den truststore vum Testclient.

REST Assured stellt trustStore fir dësen Zweck bereet. En Truststore ännert, wéi eng Aussteller den HTTPS-Client vertraut; hien wielt net de Proxy aus a liwwert net seng Umeldung. Loosst d'Validéierung vum Hostnumm a vum Zertifikat ageschalt, amplaz en accept-all-Handshake ze benotzen, fir all Zertifikat ze akzeptéieren, dat presentéiert gëtt.

Ähnlech Artikelen