O REST Assured tem uma especificação de proxy que carrega juntos o endereço e as credenciais do intermediário:

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

A aplicação fornece proxyUser e proxyPassword a partir da sua fonte habitual de credenciais. O trecho constrói uma especificação de requisição; invoque o URL da API desejada por meio de request com o código habitual de requisição e verificação do teste.

O esquema http descreve o endpoint do proxy. O URL da API pode permanecer HTTPS. O mecanismo withAuth do REST Assured fornece autenticação básica de proxy; ele não negocia todos os esquemas de autenticação corporativos só porque duas strings foram fornecidas.

Coloque as credenciais da API na configuração de autenticação da própria API. Evite substituir a conta do proxy por um cabeçalho Authorization genérico ou por uma senha de serviço. Em HTTPS, a autenticação com o intermediário pode ser necessária ao estabelecer CONNECT, antes de existir a troca HTTP com o destino.

Quando a falha restante é a confiança no certificado

Um desafio CONNECT rejeitado e um erro de validação de certificado TLS são resultados diferentes. Se a CA exigida e gerida pela organização faltar na configuração de confiança do cliente, obtenha essa CA pelo canal administrativo aprovado e configure o truststore do cliente de teste.

O REST Assured expõe trustStore para esse fim. Um truststore altera quais emissores o cliente HTTPS confia; ele não escolhe o proxy nem fornece o login dele. Mantenha a validação de nome de host e de certificado ativada em vez de usar um handshake accept-all para aceitar qualquer certificado apresentado.

Artigos relacionados