Java-proxyfel 407: kontrollera Basic-autentisering för CONNECT

Begränsa Java-inloggningsuppgifterna till proxyn och kontrollera JDK:s separata policy för Basic-autentisering i HTTPS-CONNECT-tunnlar.

Upprepade 407 betyder inte alltid att Java skickade fel lösenord. JDK:s referensimplementation inaktiverar normalt Basic-autentisering för HTTPS-CONNECT-tunnlar. En proxy som bara erbjuder Basic kan avvisas innan din autentiseringscallback lämnar inloggningsuppgifter.

Begränsa räckvidden för callbacken som lämnar inloggningsuppgifter

Koppla en Authenticator till Java-HTTP-klienten och begränsa den till den konfigurerade proxyn:

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

Detta är inställningskod för en klient, inte en global standardautentiserare. Byt ut dokumentationsadressen och använd uppgifter som faktiskt har tilldelats för tjänsten. Kontrollerna av begärartyp och ändpunkt hindrar samma callback från att obetänksamt lämna proxykontot vid en autentiseringsutmaning från en webbplats.

Kontrollera vilket autentiseringssteg som misslyckas

JDK har separata inställningar för inaktiverade scheman för vanlig HTTP-proxytrafik och CONNECT-tunnlar. De aktuella namnen är jdk.http.auth.proxying.disabledSchemes och jdk.http.auth.tunneling.disabledSchemes.

Det förklarar varför HTTP-trafik kan autentiseras medan en HTTPS-tunnel genom samma proxy misslyckas. Kontrollera körmiljöns conf/net.properties och distributionspolicyn i stället för att anta att en annan dator har samma gällande standardvärden.

Att tömma en lista över inaktiverade scheman globalt är ingen allmän proxylösning. Basic-inloggningsuppgifter som skickas till en HTTP-proxy i klartext skyddas inte av den senare TLS-anslutningen till destinationen. Granska proxytransporten, autentiseringsmetoden och distributionspolicyn innan du godkänner en ändring.

Det dokumenterade beteendet hos JDK:s inbyggda autentisering lovar inte heller stöd för varje schema som en proxy annonserar. Ett manuellt angivet Authorization- eller Proxy-Authorization-huvud ändrar det automatiska autentiseringsflödet, så kontrollera anpassade huvuden när callbacken beter sig annorlunda än i exemplet.

Relaterade artiklar