Erori 407 de proxy în Java: verificați autentificarea Basic pentru CONNECT

Limitați acreditările Java la proxy și verificați politica separată a JDK pentru autentificarea Basic în tunelurile HTTPS CONNECT.

Un 407 repetat nu înseamnă întotdeauna că Java a trimis parola greșită. Implementarea de referință JDK dezactivează de obicei autentificarea Basic pentru tunelurile HTTPS CONNECT. Un proxy care oferă numai Basic poate fi respins înainte ca funcția de callback pentru autentificare să furnizeze acreditările.

Limitați domeniul callbackului pentru acreditări

Atașați un Authenticator la clientul HTTP Java și limitați-l la proxy-ul configurat:

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

Acesta este cod de configurare pentru un client, nu un autentificator implicit global. Înlocuiți adresa de documentație și folosiți acreditările furnizate efectiv pentru acel serviciu. Verificările tipului solicitantului și ale punctului final împiedică același callback să ofere neglijent contul proxy-ului la o provocare de autentificare a unui site.

Verificați ce etapă de autentificare eșuează

JDK are setări separate pentru schemele dezactivate în cazul traficului HTTP obișnuit prin proxy și al tunelurilor CONNECT. Numele relevante sunt jdk.http.auth.proxying.disabledSchemes și jdk.http.auth.tunneling.disabledSchemes.

Aceasta explică de ce traficul HTTP se poate autentifica, în timp ce un tunel HTTPS prin același proxy eșuează. Verificați conf/net.properties al mediului de execuție și politica de implementare, în loc să presupuneți că alt calculator are aceleași valori implicite efective.

Golirea globală a listei de scheme dezactivate nu este o remediere generală pentru proxy. Acreditările Basic trimise unui proxy HTTP în clar nu sunt protejate de conexiunea TLS ulterioară cu destinația. Examinați transportul proxy-ului, metoda de autentificare și politica de implementare înainte de a aproba o modificare.

Comportamentul documentat al autentificării integrate în JDK nu promite nici el suport pentru fiecare schemă anunțată de un proxy. Un antet Authorization sau Proxy-Authorization furnizat manual modifică fluxul autentificatorului automat, așa că inspectați antetele personalizate când callbackul se comportă diferit de exemplu.

Articole similare