Autentikimi bazë i përfaqësuesit për një kërkesë REST Assured

REST Assured ka një specifikim përfaqësuesi që mban bashkë adresën dhe kredencialet e ndërmjetësit:

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

Aplikacioni furnizon proxyUser dhe proxyPassword nga burimi i tij i zakonshëm i kredencialeve. Fragmenti ndërton një specifikim kërkese; thirrni URL-në e synuar të API-t përmes request me kodin e zakonshëm të kërkesës dhe të verifikimit të testit.

Skema http përshkruan pikën fundore të përfaqësuesit. URL-ja e API-t mund të mbetet HTTPS. Mekanizmi withAuth i REST Assured ofron autentikim bazë të përfaqësuesit; ai nuk negocion çdo skemë autentikimi korporativ vetëm sepse u dhanë dy vargje.

Vendosni kredencialet e API-t në konfigurimin e autentikimit të vetë API-t. Shmangni zëvendësimin e llogarisë së përfaqësuesit me një header Authorization të përgjithshëm ose me një fjalëkalim shërbimi. Në HTTPS, autentikimi te ndërmjetësi mund të jetë i nevojshëm gjatë vendosjes së CONNECT, përpara se të ekzistojë shkëmbimi HTTP me destinacionin.

Kur dështimi i mbetur është besimi te certifikata

Një sfidë CONNECT e refuzuar dhe një gabim validimi i certifikatës TLS janë rezultate të ndryshme. Nëse CA-ja e kërkuar e administruar nga organizata mungon në konfigurimin e besimit të klientit, sigurojeni atë përmes kanalit administrativ të miratuar dhe konfiguroni truststore-in e klientit të testit.

REST Assured ekspozon trustStore për atë qëllim. Një truststore ndryshon cilët lëshues klienti HTTPS i beson; nuk e zgjedh përfaqësuesin dhe nuk jep identifikimin e tij. Mbani aktiv validimin e emrit të hostit dhe të certifikatës, në vend që të përdorni një shtrëngim duarsh accept-all për të pranuar çdo certifikatë që paraqitet.