Помилки проксі 407 у Java: перевірте Basic-автентифікацію для CONNECT

Обмежте облікові дані Java потрібним проксі та перевірте окрему політику JDK щодо Basic-автентифікації в тунелях HTTPS CONNECT.

Повторюваний 407 не завжди означає, що Java надіслала неправильний пароль. Еталонна реалізація JDK зазвичай вимикає Basic-автентифікацію для тунелів HTTPS CONNECT. Проксі, що пропонує лише Basic, може бути відхилено ще до того, як ваш обробник автентифікації надасть облікові дані.

Обмежте область дії обробника облікових даних

Призначте Authenticator HTTP-клієнту Java та обмежте його налаштованим проксі:

String proxyHost = "203.0.113.10";
int proxyPort = 8080;
String password = System.getenv("PROXY_PASSWORD");
if (password == null) {
    throw new IllegalStateException("Set PROXY_PASSWORD");
}

java.net.Authenticator auth = new java.net.Authenticator() {
    @Override
    protected java.net.PasswordAuthentication getPasswordAuthentication() {
        if (getRequestorType() == RequestorType.PROXY
                && proxyHost.equals(getRequestingHost())
                && proxyPort == getRequestingPort()) {
            return new java.net.PasswordAuthentication(
                "proxy-user", password.toCharArray());
        }
        return null;
    }
};

java.net.http.HttpClient client = java.net.http.HttpClient.newBuilder()
    .proxy(java.net.ProxySelector.of(
        new java.net.InetSocketAddress(proxyHost, proxyPort)))
    .authenticator(auth)
    .connectTimeout(java.time.Duration.ofSeconds(5))
    .build();

Це код налаштування одного клієнта, а не глобальний типовий автентифікатор. Замініть адресу для документації та використовуйте облікові дані, справді надані для цього сервісу. Перевірки типу запитувача й кінцевої точки не дають тому самому обробнику необачно запропонувати обліковий запис проксі у відповідь на запит автентифікації від сайту.

Перевірте, який етап автентифікації завершується невдало

JDK має окремі налаштування вимкнених схем для звичайного передавання HTTP через проксі та для тунелів CONNECT. Відповідні назви — jdk.http.auth.proxying.disabledSchemes і jdk.http.auth.tunneling.disabledSchemes.

Це пояснює, чому HTTP-трафік може пройти автентифікацію, тоді як тунель HTTPS через той самий проксі не працює. Перевірте conf/net.properties середовища виконання й політику розгортання, а не припускайте, що на іншій машині діють ті самі типові значення.

Глобальне очищення списку вимкнених схем — не універсальне виправлення проксі. Облікові дані Basic, надіслані незашифрованому HTTP-проксі, не захищені подальшим TLS-з'єднанням із цільовим сервером. Перш ніж схвалити зміну, оцініть транспорт до проксі, метод автентифікації та політику розгортання.

Задокументована поведінка вбудованої автентифікації JDK також не обіцяє підтримки кожної схеми, яку оголошує проксі. Вручну заданий заголовок Authorization або Proxy-Authorization змінює перебіг автоматичної автентифікації, тому перевірте власні заголовки, якщо обробник поводиться інакше, ніж у прикладі.

Схожі статті