Вход в прокси относится к поставщику учетных данных транспорта. Для 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, не эквивалентен этим переговорам.

Настраивайте любую учетную запись назначения отдельно. Если прокси по-прежнему отклоняет запрос, сохраните объявленную им схему аутентификации, а также фактический хост и порт. Учетные данные, ограниченные другой конечной точкой, не совпадут только потому, что пароль верен.

Похожие статьи