Основна прокси аутентификација за 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. REST Assured механизам withAuth пружа основну прокси аутентификацију; не преговара сваку корпоративну аутентификациону шему само зато што су достављена два низа.

Сместите API акредитиве у сопствену аутентификациону конфигурацију API-ја. Избегните замену прокси налога општим Authorization заглављем или сервисном лозинком. За HTTPS, аутентификација према посреднику може бити потребна при успостављању CONNECT-а, пре него што размена HTTP са одредиштем уопште постоји.

Када је преостали квар поверење у сертификат

Одбијени CONNECT изазов и грешка провере TLS сертификата различити су исходи. Ако потребни CA којим управља организација недостаје у клијентовом распореду поверења, набавите тај CA одобреним административним каналом и конфигуришите truststore тестног клијента.

REST Assured у ту сврху излаже trustStore. Truststore мења којима издаваоцима HTTPS клијент верује; не одабире прокси нити даје његову пријаву. Држите проверу имена хоста и сертификата укљученом уместо да користите accept-all руковање како бисте прихватили који год сертификат био представљен.

Повезани чланци