Ponavljani 407 ne znači uvijek da je Java poslala pogrešnu lozinku. Referentna JDK implementacija obično onemogućuje Basic autentifikaciju za HTTPS CONNECT tuneliranje. Proxy koji nudi samo Basic može biti odbijen prije nego što vaš autentifikacijski callback dostavi podatke.

Ograničite opseg callbacka za pristupne podatke

Dodajte Authenticator na Java HTTP klijent i ograničite ga na konfigurirani proxy:

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

Ovo je kod postavljanja klijenta, ne globalni zadani autentifikator. Zamijenite dokumentacijsku adresu i koristite podatke stvarno dodijeljene za tu uslugu. Provjere tipa podnositelja zahtjeva i krajnje točke sprečavaju isti callback da olako ponudi proxy račun na autentifikacijski zahtjev web-mjesta.

Provjerite koja faza autentifikacije ne uspijeva

JDK ima odvojene postavke onemogućenih shema za obično HTTP proksiranje i CONNECT tuneliranje. Nazivi su jdk.http.auth.proxying.disabledSchemes i jdk.http.auth.tunneling.disabledSchemes.

To objašnjava zašto HTTP promet može proći autentifikaciju dok HTTPS tunel kroz isti proxy ne uspijeva. Provjerite conf/net.properties korištenog izvršnog okruženja i politiku implementacije, umjesto pretpostavke da drugo računalo ima iste efektivne zadane vrijednosti.

Globalno pražnjenje popisa onemogućenih shema nije opći popravak proxyja. Basic podatke poslane nešifriranom HTTP proxyju ne štiti kasnija TLS veza s odredištem. Pregledajte proxy transport, način autentifikacije i politiku implementacije prije odobravanja promjene.

Dokumentirano ugrađeno autentifikacijsko ponašanje JDK-a nije ni obećanje podrške za svaku shemu koju proxy oglašava. Ručno postavljeno zaglavlje Authorization ili Proxy-Authorization mijenja tok automatskog autentifikatora, pa pregledajte prilagođena zaglavlja kada se callback ponaša drukčije od primjera.

Povezani članci