O login no proxy pertence ao provedor de credenciais do transporte. Com Spring 6 e Apache HttpClient 5, limite essa conta ao intermediário:

var proxy = new org.apache.hc.core5.http.HttpHost(
    "http", "proxy.example", 8080);
var credentials = new org.apache.hc.client5.http.impl.auth
    .BasicCredentialsProvider();
credentials.setCredentials(
    new org.apache.hc.client5.http.auth.AuthScope(proxy),
    new org.apache.hc.client5.http.auth.UsernamePasswordCredentials(
        proxyUser, proxyPassword.toCharArray()));

var http = org.apache.hc.client5.http.impl.classic.HttpClients.custom()
    .setProxy(proxy)
    .setDefaultCredentialsProvider(credentials)
    .build();
var factory = new org.springframework.http.client
    .HttpComponentsClientHttpRequestFactory(http);
var rest = new org.springframework.web.client.RestTemplate(factory);

A aplicação fornece os valores proxyUser e proxyPassword e é dona do ciclo de vida do cliente HTTP. Reutilize rest para a carga de trabalho em vez de construir outro modelo padrão no local da chamada.

O AuthScope limita onde essas credenciais são elegíveis. O exemplo fornece credenciais comuns de nome de usuário/senha; o nome BasicCredentialsProvider não força cada desafio a usar o esquema HTTP Basic.

Com um destino HTTPS, o transporte pode responder a um desafio do proxy durante o CONNECT, antes que a solicitação HTTP criptografada da aplicação exista. Um interceptor de destino genérico que adiciona Proxy-Authorization não equivale a essa negociação.

Configure qualquer conta de destino separadamente. Se o proxy ainda rejeitar a solicitação, mantenha o esquema de autenticação anunciado e o host e a porta efetivos. Uma credencial limitada a outro endpoint não corresponderá só porque a senha está correta.

Artigos relacionados