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

Подобни статии