Pamata starpniekservera autentifikācija REST Assured pieprasījumam

Izmantojiet ProxySpecification starpnieka adresei un kontam, bet uzticēšanās konfigurāciju atstājiet HTTPS klientā.

REST Assured ir starpniekservera specifikācija, kas kopā pārnēsā starpnieka adresi un akreditācijas datus:

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

Lietojumprogramma nodrošina proxyUser un proxyPassword no sava parastā akreditācijas datu avota. Šis fragments veido pieprasījuma specifikāciju; izsauciet paredzēto API URL, izmantojot request un testa parasto pieprasījuma un pārbaudes kodu.

http shēma apraksta starpniekservera galapunktu. API URL var palikt HTTPS. REST Assured withAuth mehānisms nodrošina pamata starpniekservera autentifikāciju; tas nepārrunā visas uzņēmuma autentifikācijas shēmas tikai tāpēc, ka tika dotas divas virknes.

Ievietojiet API akreditācijas datus paša API autentifikācijas konfigurācijā. Izvairieties aizstāt starpnieka kontu ar vispārīgu Authorization galveni vai servisa paroli. HTTPS gadījumā autentifikācija pie starpnieka var būt nepieciešama, veidojot CONNECT, pirms vēl pastāv HTTP apmaiņa ar galamērķi.

Kad atlikušā kļūda ir sertifikāta uzticēšanās

Noraidīts CONNECT izaicinājums un TLS sertifikāta validācijas kļūda ir atšķirīgi rezultāti. Ja nepieciešamais organizācijas pārvaldītais CA trūkst klienta uzticēšanās iestatījumā, iegūstiet šo CA apstiprinātajā administratīvajā kanālā un konfigurējiet testa klienta truststore.

REST Assured šim nolūkam publisko trustStore. Truststore maina, kuriem izdevējiem HTTPS klients uzticas; tas neizvēlas starpnieku un nenodrošina tā pieteikšanos. Atstājiet iespējotu resursdatora nosaukuma un sertifikāta validāciju, nevis izmantojiet accept-all rokasspiedienu, lai pieņemtu jebkuru uzrādīto sertifikātu.

Saistītie raksti