Java-prokurilaj eraroj 407: kontrolu Basic-aŭtentikigon por CONNECT

Limigu Java-prokurilajn ensalutilojn al la prokurilo kaj kontrolu la apartan Basic-aŭtentikigan politikon de JDK por HTTPS CONNECT-tuneloj.

Ripeta 407 ne ĉiam signifas, ke Java sendis malĝustan pasvorton. La referenca JDK-efektivigo normale malebligas Basic-aŭtentikigon por HTTPS CONNECT-tuneloj. Prokurilo ofertanta nur Basic povas esti rifuzita antaŭ ol via aŭtentikiga revokfunkcio liveras ensalutilojn.

Limigu la amplekson de la ensalutila revokfunkcio

Aligu Authenticator al la Java-HTTP-kliento kaj limigu ĝin al la agordita prokurilo:

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

Ĉi tio estas agorda kodo por kliento, ne tutmonda defaŭlta aŭtentikigilo. Anstataŭigu la dokumentan adreson kaj uzu ensalutilojn vere donitajn por tiu servo. La kontroloj de petanttipo kaj finpunkto malhelpas, ke la sama revokfunkcio senpripense oferu la prokurilan konton al reteja aŭtentikiga defio.

Kontrolu, kiu aŭtentikiga fazo malsukcesas

JDK havas apartajn malebligitajn skemagordojn por ordinara HTTP-prokurado kaj CONNECT-tunelado. La nomoj estas jdk.http.auth.proxying.disabledSchemes kaj jdk.http.auth.tunneling.disabledSchemes.

Tio klarigas kial HTTP-trafiko povas aŭtentikiĝi dum HTTPS-tunelo tra la sama prokurilo malsukcesas. Kontrolu conf/net.properties de la rultempa medio kaj la deplojan politikon anstataŭ supozi samajn efektivajn defaŭltojn sur alia maŝino.

Tutmonde malplenigi liston de malebligitaj skemoj ne estas ĝenerala prokurila riparo. Basic-ensalutiloj senditaj al klarteksta HTTP-prokurilo ne estas protektataj de la posta TLS-konekto al la celo. Reviziu la prokurilan transporton, aŭtentikigan metodon kaj deplojan politikon antaŭ aprobi ŝanĝon.

La dokumentita enkonstruita aŭtentikiga konduto de JDK ankaŭ ne promesas subteni ĉiun skemon reklamitan de prokurilo. Mane donita kaplinio Authorization aŭ Proxy-Authorization ŝanĝas la aŭtomatan aŭtentikigilan fluon, do kontrolu proprajn kapliniojn kiam la revokfunkcio kondutas malsame ol la ekzemplo.

Rilataj artikoloj