REST Assured hat in proxy-spesifikaasje dy't it adres en de bewizen fan de tuskenpersoan mei-inoar draacht:

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

De applikaasje leveret proxyUser en proxyPassword út syn gewoane boarne fan bewizen. It fragmint bout in oanfraachspesifikaasje; rop de bedoelde API-URL oan fia request mei de gewoane oanfraach- en kontrôlekoade fan de test.

It http-skema beskriuwt it einpunt fan de proxy. De API-URL kin HTTPS bliuwe. It withAuth-meganisme fan REST Assured leveret basisproxy-ferifikaasje; it ûnderhannelt net elk bedriuwsferifikaasjeskema allinnich om't twa strings oanlevere binne.

Set API-bewizen yn 'e eigen ferifikaasjekonfiguraasje fan 'e API. Foarkom dat it proxy-akkount ferfongen wurdt troch in algemiene Authorization-kop of in tsjinstwachtwurd. By HTTPS kin ferifikaasje by de tuskenpersoan nedich wêze by it opbouwen fan CONNECT, foardat de HTTP-útwikseling mei de bestimming bestiet.

As de oerbleaune flater fertrouwen yn it sertifikaat is

In wegere CONNECT-útdaging en in TLS-sertifikaatfalidaasjeflater binne ferskillende útkomsten. As de fereaske, troch de organisaasje behearde CA ûntbrekt yn 'e fertrouwensregeling fan 'e klient, helje dy CA dan fia it goedkarde bestjoerlike kanaal en konfigurearje de truststore fan 'e testklient.

REST Assured eksposearret trustStore foar dat doel. In truststore feroaret hokker útjouwers de HTTPS-klient fertrout; it kiest de proxy net en leveret syn oanmelding net. Hâld hostnamme- en sertifikaatfalidaasje ynskeakele ynstee fan in accept-all-hânskot te brûken om hokker sertifikaat dan ek oanbean te akseptearjen.

Relatearre artikelen