REST Assured sisaldab puhverserveri spetsifikatsiooni, mis kannab vahendaja aadressi ja volitusi koos:

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

Rakendus annab proxyUser ja proxyPassword oma tavalisest volituste allikast. See fragment koostab päringu spetsifikatsiooni; kutsuge soovitud API URL välja request kaudu, kasutades testi tavalist päringu- ja kontrollkoodi.

Skeem http kirjeldab puhverserveri lõpp-punkti. API URL võib jääda HTTPS-iks. REST Assuredi withAuth mehhanism pakub põhilist puhverserveri autentimist; see ei läbi läbirääkimisi kõigi ettevõtte autentimisskeemidega ainult seetõttu, et anti kaks stringi.

Paigutage API volitused API enda autentimiskonfiguratsiooni. Vältige puhverserveri konto asendamist üldise Authorization-päise või teenuse parooliga. HTTPS-i puhul võib autentimine vahendaja juures olla vajalik CONNECT-i loomise ajal, enne kui sihtkohaga HTTP-vahetus üldse tekib.

Kui allesjäänud tõrge on sertifikaadi usaldus

Tagasi lükatud CONNECT-väljakutse ja TLS-sertifikaadi valideerimise viga on erinevad tulemused. Kui nõutav organisatsiooni hallatav CA puudub kliendi usaldusseadistusest, hankige see CA heakskiidetud halduskanali kaudu ja seadistage testkliendi truststore.

REST Assured pakub selleks trustStore'i. Truststore muudab, milliseid väljaandjaid HTTPS-klient usaldab; see ei vali puhverserverit ega anna selle sisselogimist. Hoidke hostinime ja sertifikaadi valideerimine sisse lülitatud, selle asemel et kasutada accept-all kätlust ja võtta vastu ükskõik milline esitatud sertifikaat.

Seotud artiklid