Grundleggjandi proxy-autentisering til eina REST Assured-fyrispurning

Nýt ProxySpecification til adressu og konto hjá millumgongdini, og lat trúnaðarstillingarnar vera á HTTPS-klientinum.

REST Assured hevur eina proxy-specifikatjón, sum ber adressuna og váttanirnar hjá millumgongdini saman:

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

Forritið veitir proxyUser og proxyPassword frá sínum vanliga váttanarkelda. Stubben byggir eina fyrispurnarspecifikatjón; kalla tíð API-URL'ina gjøgnum request við vanliga fyrispurnar- og váttanarkota royndarinnar.

http-skemaið lýsir endapuntin hjá proxynum. API-URL'in kann verða verandi HTTPS. withAuth-mekanismin í REST Assured veitir grundleggjandi proxy-autentisering; hon samráðist ikki við øll felagsautentiseringsskemai bara tí, at tveir strengir vórðu latnir.

Set API-váttanirnar í egna autentiseringsstilling API'isins. Forða tær frá at seta proxy-kontuna í staðin fyri eina almenna Authorization-yvirskrift ella eitt tænastuloyniorð. Á HTTPS kann autentisering móti millumgongdini vera neyðug, meðan CONNECT verður sett á stovn, áðrenn HTTP-útskiftið við málið er til.

Tá ið tann eftirverandi bresturin er trúnaður til skírið

Ein avvíst CONNECT-avbjóðing og ein váttanarbrestur í TLS-skíri eru ymisk úrslit. Um tann kravdi CA'in, sum felagið stýrir, manglar í trúnaðaruppsetningini hjá klientinum, fá so tað CA'ina gjøgnum tað góðkendu fyrisitingarleiðina og set truststore hjá royndarklientinum.

REST Assured vísir trustStore til hetta endamálið. Eitt truststore broytir, hvørjum útgevarum HTTPS-klienturin trýr; tað velur ikki proxyn og veitir ikki innritanina hjá tí. Lat vertsnavn- og skíriváttan vera virkna í staðin fyri at brúka eitt accept-all-hondtak at taka ímóti, hvørjum skíri sum helst verður lagt fram.

Skyldar greinar