Основно удостоверяване на прокси за заявка с 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 ръкостискане, за да приемете какъвто сертификат бъде представен.