Ограничете ги proxy-акредитивите на RestTemplate со HttpClient 5

Најавувањето на proxy ѝ припаѓа на доведувачот на акредитиви на транспортот. Со Spring 6 и Apache HttpClient 5, ограничете ја таа сметка на посредникот:

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

Апликацијата ги обезбедува вредностите proxyUser и proxyPassword и го поседува животниот циклус на HTTP-клиентот. Повторно користете rest за работното оптоварување наместо да градите друга стандардна шаблона на местото на повикот.

AuthScope ограничува каде овие акредитиви се важечки. Примерот обезбедува обични акредитиви за корисничко име и лозинка; името BasicCredentialsProvider не принудува секој предизвик да ја користи шемата HTTP Basic.

Со HTTPS-дестинација, транспортот може да одговори на proxy-предизвик за време на CONNECT, пред да постои шифрираното HTTP-барање на апликацијата. Општ пресретнувач на дестинација што додава Proxy-Authorization не е еквивалентен на тоа преговарање.

Конфигурирајте ја секоја сметка за дестинација одделно. Ако proxy сè уште го одбива барањето, задржете ја објавената шема за автентикација и вистинскиот хост и порта. Акредитивите ограничени на друга крајна точка нема да се совпаднат само затоа што лозинката е точна.