Прокси грешки 407 в Java: проверете Basic удостоверяването за CONNECT
Ограничете идентификационните данни на Java до проксито и проверете отделната политика на JDK за Basic удостоверяване в HTTPS CONNECT тунели.
Повтарящ се 407 не винаги означава, че Java е изпратила грешна парола. Референтната реализация на JDK обикновено забранява Basic удостоверяването за HTTPS CONNECT тунели. Прокси, което предлага само Basic, може да бъде отхвърлено, преди вашата функция за обратно извикване за удостоверяване да предостави данните.
Ограничете обхвата на функцията за идентификационни данни
Свържете Authenticator с Java HTTP клиента и го ограничете до настроеното прокси:
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 променя потока на автоматичния удостоверител, затова проверете персонализираните хедъри, когато функцията се държи различно от примера.