Памылкі проксі 407 у Java: праверце аўтэнтыфікацыю Basic для CONNECT

Абмяжуйце ўліковыя даныя Java патрэбным проксі і праверце асобную палітыку JDK для аўтэнтыфікацыі Basic у тунэлях HTTPS CONNECT.

Паўторны 407 не заўсёды азначае, што Java адправіла няправільны пароль. Эталонная рэалізацыя JDK звычайна адключае аўтэнтыфікацыю Basic для тунэляў HTTPS CONNECT. Проксі, які прапануе толькі Basic, можа быць адхілены яшчэ да таго, як ваш зваротны выклік аўтэнтыфікацыі падасць уліковыя даныя.

Абмяжуйце вобласць дзеяння зваротнага выкліку для ўліковых даных

Прызначце Authenticator HTTP-кліенту Java і абмяжуйце яго наладжаным проксі:

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

Гэта код наладжвання аднаго кліента, а не глабальны стандартны аўтэнтыфікатар. Замяніце адрас для дакументацыі і выкарыстоўвайце ўліковыя даныя, сапраўды выдадзеныя для гэтай службы. Праверкі тыпу запытальніка і канцавога пункта не дазваляюць таму ж зваротнаму выкліку неабдумана прапанаваць уліковы запіс проксі ў адказ на запыт аўтэнтыфікацыі ад сайта.

Праверце, на якім этапе аўтэнтыфікацыя дае збой

JDK мае асобныя налады адключаных схем для звычайнага перадавання HTTP праз проксі і для тунэляў CONNECT. Адпаведныя назвы — jdk.http.auth.proxying.disabledSchemes і jdk.http.auth.tunneling.disabledSchemes.

Гэта тлумачыць, чаму HTTP-трафік можа прайсці аўтэнтыфікацыю, а тунэль HTTPS праз той жа проксі — не. Праверце conf/net.properties асяроддзя выканання і палітыку разгортвання замест таго, каб меркаваць, што на іншай машыне дзейнічаюць тыя ж стандартныя значэнні.

Глабальнае ачышчэнне спіса адключаных схем — не ўніверсальнае выпраўленне проксі. Уліковыя даныя Basic, адпраўленыя незашыфраванаму HTTP-проксі, не абароненыя пазнейшым TLS-злучэннем з мэтай. Перад ухваленнем змены ацаніце транспарт да проксі, метад аўтэнтыфікацыі і палітыку разгортвання.

Задакументаваныя паводзіны ўбудаванай аўтэнтыфікацыі JDK таксама не абяцаюць падтрымку кожнай схемы, якую абвяшчае проксі. Уручную зададзены загаловак Authorization або Proxy-Authorization змяняе ход аўтаматычнай аўтэнтыфікацыі, таму праверце ўласныя загалоўкі, калі зваротны выклік паводзіць сябе інакш, чым у прыкладзе.

Падобныя артыкулы