خطاهای 407 پروکسی در Java: احراز هویت Basic برای 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 که دستی ارائه شود جریان احرازکنندهٔ خودکار را تغییر می‌دهد؛ پس اگر رفتار تابع بازخوانی با نمونه متفاوت بود، سرآیندهای سفارشی را بررسی کنید.