Влизането през прокси принадлежи на доставчика на идентификационни данни на транспорта. За 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 дестинация транспортът може да отговори на прокси предизвикателство по време на CONNECT, преди да съществува криптираната HTTP заявка на приложението. Общ интерцептор за дестинация, който добавя Proxy-Authorization, не е еквивалентен на тази договорка.

Конфигурирайте всеки акаунт за дестинация отделно. Ако проксито все още отхвърля заявката, запазете обявената от него схема за удостоверяване и действителните хост и порт. Ограничени идентификационни данни за друга крайна точка няма да съвпаднат само защото паролата е правилна.

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