REST Assuredissa on välityspalvelinmääritelmä, joka kuljettaa välittäjän osoitteen ja tunnistetiedot yhdessä:

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

Sovellus toimittaa proxyUser- ja proxyPassword-arvot tavallisesta tunnistetietolähteestään. Katkelma rakentaa pyyntömääritelmän; kutsu aiottu API-osoite request-olion kautta testin tavallisella pyyntö- ja tarkistuskoodilla.

http-skeema kuvaa välityspalvelimen päätepisteen. API-osoite voi pysyä HTTPS:nä. REST Assuredin withAuth-mekanismi tarjoaa perusvälityspalvelimen todennuksen; se ei neuvottele kaikkien yritystodennusmenetelmien kanssa vain siksi, että kaksi merkkijonoa annettiin.

Sijoita API-tunnistetiedot API:n omaan todennusasetukseen. Vältä välityspalvelimen tilin korvaamista yleisellä Authorization-otsakkeella tai palvelun salasanalla. HTTPS:ssä välittäjään kohdistuva todennus voi olla tarpeen CONNECT-yhteyttä muodostettaessa, ennen kuin kohdekohtaista HTTP-vaihtoa on olemassa.

Kun jäljellä oleva virhe on varmenteen luottamus

Hylätty CONNECT-haaste ja TLS-varmenteen vahvistusvirhe ovat eri tuloksia. Jos vaadittu organisaation hallitsema CA puuttuu asiakkaan luottamusjärjestelystä, hanki se hyväksyttyä hallintakanavaa pitkin ja määritä testiasiakkaan truststore.

REST Assured tarjoaa tähän trustStore-asetuksen. Truststore muuttaa, mihin myöntäjiin HTTPS-asiakas luottaa; se ei valitse välityspalvelinta eikä tarjoa sen kirjautumista. Pidä isäntänimen ja varmenteen vahvistus käytössä sen sijaan, että käyttäisit accept-all-kättelyä minkä tahansa esitetyn varmenteen hyväksymiseen.

Aiheeseen liittyvät artikkelit