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.

Erlazionatutako artikuluak