Baza prokura aŭtentigo por REST Assured-peto

Uzu ProxySpecification por la adreso kaj konto de la peranto, kaj lasu la fidan agordon ĉe la HTTPS-kliento.

REST Assured havas prokuran specifon, kiu portas la adreson kaj la akreditaĵojn de la peranto kune:

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

La aplikaĵo provizas proxyUser kaj proxyPassword el sia kutima fonto de akreditaĵoj. La fragmento konstruas petspecifon; voku la celatan API-adreson per request uzante la kutiman petan kaj kontrolan kodon de la testoj.

La skemo http priskribas la finpunkton de la prokuro. La API-adreso povas resti HTTPS. La mekanismo withAuth de REST Assured provizas bazan prokuran aŭtentigon; ĝi ne intertraktas ĉiun entreprenan aŭtentigan skemon nur ĉar oni donis du signoĉenojn.

Metu la API-akreditaĵojn en la propran aŭtentigan agordon de la API. Evitu anstataŭigi la prokuran konton per ĝenerala Authorization-kapo aŭ per servo-pasvorto. Ĉe HTTPS, aŭtentigo al la peranto povas esti bezonata dum starigo de CONNECT, antaŭ ol ekzistas la HTTP-interŝanĝo kun la celo.

Kiam la cetera fiasko estas fido al atestilo

Malakceptita CONNECT-defio kaj eraro de validigo de TLS-atestilo estas malsamaj rezultoj. Se la bezonata CA administrata de la organizo mankas en la fida aranĝo de la kliento, akiru tiun CA per la aprobita administra kanalo kaj agordu la truststore de la testa kliento.

REST Assured elmetas trustStore por tiu celo. Truststore ŝanĝas, kiujn eldonantojn la HTTPS-kliento fidas; ĝi ne elektas la prokuron nek provizas ĝian saluton. Lasu la validigon de gastignomo kaj atestilo ebligita anstataŭ uzi accept-all-intermanon por akcepti ajnan prezentatan atestilon.

Rilataj artikoloj