Базавая аўтэнтыфікацыя проксі для запыту REST Assured

Выкарыстоўвайце ProxySpecification для адрасу і ўліковага запісу пасярэдніка, а налады даверу пакідайце на HTTPS-кліенце.

У REST Assured ёсць спецыфікацыя проксі, якая разам пераносіць адрас пасярэдніка і яго ўліковыя даныя:

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

Прыкладанне падае proxyUser і proxyPassword са сваёй звычайнай крыніцы ўліковых даных. Гэты фрагмент будуе спецыфікацыю запыту; выклікайце патрэбны API URL праз request, выкарыстоўваючы звычайны код запыту і праверкі тэсту.

Схема http апісвае канчатковую кропку проксі. API URL можа заставацца HTTPS. Механізм withAuth у REST Assured забяспечвае базовую аўтэнтыфікацыю проксі; ён не ўзгадняе ўсе карпаратыўныя схемы аўтэнтыфікацыі толькі таму, што былі перададзены два радкі.

Размяшчайце ўліковыя даныя API ва ўласнай канфігурацыі аўтэнтыфікацыі API. Не падмяняйце ўліковы запіс проксі агульным загалоўкам Authorization або паролем службы. Для HTTPS аўтэнтыфікацыя на пасярэдніку можа спатрэбіцца падчас усталявання CONNECT, да таго як узнікне HTTP-абмен з прызначэннем.

Калі рэшткавая памылка — гэта давер да сертыфіката

Адхілены выклік CONNECT і памылка праверкі сертыфіката TLS — розныя вынікі. Калі патрэбны кіраваны арганізацыяй CA адсутнічае ў схеме даверу кліента, атрымайце гэты CA праз ухвалены адміністрацыйны канал і наладзьце truststore тэставага кліента.

REST Assured прапануе для гэтага trustStore. Truststore змяняе, якім выдаўцам давярае HTTPS-кліент; ён не выбірае проксі і не дае яго лагін. Трымайце праверку імя хоста і сертыфіката ўключанай, замест таго каб выкарыстоўваць accept-all рукапацісканне і прымаць любы прапанаваны сертыфікат.

Падобныя артыкулы