Basiese proxy-verifikasie vir 'n REST Assured-navraag
Gebruik ProxySpecification vir die adres en rekening van die tussenbemiddelaar, en hou die trust-konfigurasie by die HTTPS-kliënt.
REST Assured het 'n proxy-spesifikasie wat die tussenbemiddelaar se adres en geloofsbriewe saam dra:
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 toepassing verskaf proxyUser en proxyPassword uit sy normale bron van geloofsbriewe. Die fragment bou 'n navraagspesifikasie; roep die beoogde API-URL deur request aan met die toets se gewone navraag- en assert-kode.
Die http-skema beskryf die proxy-eindpunt. Die API-URL kan HTTPS bly. REST Assured se withAuth-meganisme verskaf Basiese proxy-verifikasie; dit onderhandel nie elke korporatiewe verifikasieskema bloot omdat twee stringe voorsien is nie.
Plaas API-geloofsbriewe in die API se eie verifikasiekonfigurasie. Moenie 'n algemene Authorization-opskrif of 'n dienswagwoord vir die proxy-rekening in die plek daarvan gebruik nie. Vir HTTPS kan verifikasie by die tussenbemiddelaar nodig wees terwyl CONNECT opgerig word, voordat die bestemming se HTTP-uitruiling bestaan.
Wanneer die oorblywende fout sertifikaatvertroue is
'n Verwerpte CONNECT-uitdaging en 'n TLS-sertifikaatvalideringsfout is verskillende uitkomste. As die vereiste organisasie-bestuurde CA in die kliënt se trust-reëling ontbreek, verkry daardie CA deur die goedgekeurde administratiewe kanaal en stel die toetskliënt se truststore op.
REST Assured stel trustStore vir daardie doel beskikbaar. 'n Truststore verander watter uitreikers die HTTPS-kliënt vertrou; dit kies nie die proxy nie en verskaf nie die aanmelding daarvan nie. Hou gasheernaam- en sertifikaatvalidering aan eerder as om 'n accept-all-handshake te gebruik om watter sertifikaat ook al aangebied word, te aanvaar.