Java پراکسی کی 407 خرابی: CONNECT کے لیے Basic تصدیق جانچیں

بار بار 407 ملنے کا مطلب ہمیشہ یہ نہیں کہ Java نے غلط پاس ورڈ بھیجا۔ JDK کا حوالہ جاتی نفاذ عموماً HTTPS CONNECT سرنگوں کے لیے Basic تصدیق غیر فعال رکھتا ہے۔ صرف Basic پیش کرنے والی پراکسی آپ کے تصدیقی callback کی جانب سے اسناد دیے جانے سے پہلے ہی مسترد ہو سکتی ہے۔

اسناد کے callback کا دائرہ محدود رکھیں

Java HTTP کلائنٹ کے ساتھ Authenticator منسلک کریں اور اسے ترتیب دی گئی پراکسی تک محدود رکھیں:

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

یہ ایک کلائنٹ کی ترتیب کا کوڈ ہے، عالمی طے شدہ تصدیق کنندہ نہیں۔ دستاویزی پتہ بدلیں اور وہ اسناد استعمال کریں جو واقعی اس خدمت کے لیے دی گئی ہوں۔ درخواست کنندہ کی قسم اور اختتامی نقطے کی جانچ اسی callback کو ویب سائٹ کے تصدیقی چیلنج پر لاپروائی سے پراکسی کا اکاؤنٹ پیش کرنے سے روکتی ہے۔

جانچیں کہ تصدیق کا کون سا مرحلہ ناکام ہو رہا ہے

JDK میں عام HTTP پراکسی ٹریفک اور CONNECT سرنگوں کے لیے غیر فعال تصدیقی اسکیموں کی الگ ترتیبات ہیں۔ متعلقہ نام jdk.http.auth.proxying.disabledSchemes اور jdk.http.auth.tunneling.disabledSchemes ہیں۔

اسی لیے HTTP ٹریفک کی تصدیق کامیاب ہو سکتی ہے جبکہ اسی پراکسی سے HTTPS سرنگ ناکام ہو۔ یہ فرض کرنے کے بجائے کہ دوسری مشین پر بھی یکساں مؤثر طے شدہ اقدار ہیں، رن ٹائم کی conf/net.properties اور تعیناتی پالیسی دیکھیں۔

غیر فعال اسکیموں کی فہرست عالمی طور پر خالی کرنا پراکسی کی عمومی مرمت نہیں۔ غیر مرموز HTTP پراکسی کو بھیجی گئی Basic اسناد منزل سے بعد میں بننے والے TLS کنکشن کی حفاظت میں نہیں آتیں۔ تبدیلی منظور کرنے سے پہلے پراکسی ٹرانسپورٹ، تصدیقی طریقے اور تعیناتی پالیسی کا جائزہ لیں۔

JDK کی اندرونی تصدیق کا دستاویزی رویہ بھی پراکسی کی اعلان کردہ ہر اسکیم کی حمایت کا وعدہ نہیں۔ دستی طور پر دیا گیا Authorization یا Proxy-Authorization ہیڈر خودکار تصدیق کنندہ کا بہاؤ بدل دیتا ہے، اس لیے callback کا رویہ مثال سے مختلف ہو تو مخصوص ہیڈر دیکھیں۔