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 управуван од организацијата недостасува во поставеноста за доверба на клиентот, набавете го преку одобрениот административен канал и конфигурирајте truststore на тест клиентот.

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

Поврзани статии