Proxy autentifikazio oinarrizkoa REST Assured eskaera baterako
Erabili ProxySpecification bitartekariaren helbide eta konturako, eta utzi konfiantza-konfigurazioa HTTPS bezeroan.
REST Assured-ek proxy zehaztapen bat du, bitartekariaren helbidea eta kredentzialak batera daramatzana:
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);Aplikazioak proxyUser eta proxyPassword bere kredentzial iturri ohikoenetik hornitzen ditu. Fragmentuak eskaera-zehaztapen bat eraikitzen du; dei ezazu helburuko API URLa request bidez, testaren eskaera- eta egiaztapen-kode ohikoarekin.
http eskema proxyaren amaierako puntua deskribatzen du. API URLa HTTPS izaten jarrai dezake. REST Assured-en withAuth mekanismoak proxy autentifikazio oinarrizkoa ematen du; ez du enpresa-autentifikazio eskema guztiekin negoziatzen, bi kate eman direlako soilik.
Jarri API kredentzialak APIaren beraren autentifikazio-konfigurazioan. Saihestu proxy kontua Authorization goiburu orokor batekin edo zerbitzu-pasahitz batekin ordezkatzea. HTTPSn, bitartekariarekiko autentifikazioa beharrezkoa izan daiteke CONNECT ezartzean, helmugarekiko HTTP trukea existitu aurretik.
Gainerako hutsegitea ziurtagiriaren konfiantza denean
Baztertutako CONNECT erronka bat eta TLS ziurtagiriaren baliozkotze-errorea emaitza desberdinak dira. Behar den erakundeak kudeatutako CA bezeroaren konfiantza-ezarpenetik falta bada, lortu CA hori onartutako administrazio-bidearen bidez eta konfiguratu proba-bezeroaren truststore-a.
REST Assured-ek trustStore erakusten du horretarako. Truststore batek HTTPS bezeroak zein igorlerekin duen konfiantza aldatzen du; ez du proxya aukeratzen ezta haren saio-hasiera ematen ere. Mantendu ostalari-izena eta ziurtagiria baliozkotzea gaituta, aurkezten den edozein ziurtagiri onartzeko accept-all esku-emate bat erabili beharrean.