Mga error 407 ng Java proxy: suriin ang Basic authentication para sa CONNECT

Ang paulit-ulit na 407 ay hindi laging nangangahulugang maling password ang ipinadala ng Java. Karaniwang hindi pinapagana ng reference implementation ng JDK ang Basic authentication para sa HTTPS CONNECT tunnel. Maaaring tanggihan ang proxy na Basic lang ang iniaalok bago pa makapagbigay ng mga kredensiyal ang iyong authentication callback.

Limitahan ang saklaw ng callback para sa mga kredensiyal

Magkabit ng Authenticator sa Java HTTP client at limitahan ito sa naka-configure na 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();

Setup code ito para sa isang client, hindi isang pandaigdigang default authenticator. Palitan ang address na para sa dokumentasyon at gamitin ang mga kredensiyal na talagang ibinigay para sa serbisyong iyon. Pinipigilan ng pagsusuri sa uri ng humihiling at sa endpoint ang parehong callback na basta ialok ang proxy account sa isang authentication challenge mula sa website.

Suriin kung aling yugto ng authentication ang nabibigo

May hiwalay na mga setting ang JDK para sa mga hindi pinaganang scheme sa karaniwang HTTP proxying at sa CONNECT tunneling. Ang kaugnay na mga pangalan ay jdk.http.auth.proxying.disabledSchemes at jdk.http.auth.tunneling.disabledSchemes.

Ipinapaliwanag nito kung bakit maaaring magtagumpay ang authentication ng HTTP traffic habang nabibigo ang HTTPS tunnel sa parehong proxy. Suriin ang conf/net.properties ng runtime at ang patakaran sa deployment sa halip na ipagpalagay na pareho ang mga aktuwal na default sa ibang makina.

Ang pandaigdigang pag-alis ng lahat ng laman ng listahan ng mga hindi pinaganang scheme ay hindi pangkalahatang lunas sa proxy. Ang mga Basic credential na ipinadala sa isang cleartext HTTP proxy ay hindi protektado ng TLS connection sa destinasyon na gagawin pagkatapos nito. Suriin ang transport ng proxy, paraan ng authentication, at patakaran sa deployment bago aprubahan ang pagbabago.

Ang dokumentadong kilos ng built-in authentication ng JDK ay hindi rin pangakong susuportahan ang bawat scheme na inaanunsiyo ng proxy. Binabago ng manu-manong ibinigay na Authorization o Proxy-Authorization header ang daloy ng awtomatikong authenticator, kaya siyasatin ang mga custom header kapag iba sa halimbawa ang kilos ng callback.