Java प्रॉक्सी की 407 त्रुटियाँ: CONNECT के लिए Basic प्रमाणीकरण जाँचें

बार-बार 407 आने का अर्थ हमेशा यह नहीं होता कि Java ने गलत पासवर्ड भेजा। JDK का संदर्भ कार्यान्वयन सामान्यतः HTTPS CONNECT टनलिंग के लिए Basic प्रमाणीकरण बंद रखता है। केवल Basic देने वाला प्रॉक्सी आपके प्रमाणीकरण कॉलबैक के क्रेडेंशियल देने से पहले ही अस्वीकार हो सकता है।

क्रेडेंशियल कॉलबैक का दायरा सीमित रखें

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

यह एक क्लाइंट का सेटअप कोड है, कोई वैश्विक डिफ़ॉल्ट प्रमाणक नहीं। दस्तावेज़ वाला पता बदलें और उस सेवा के लिए वास्तव में दिए गए क्रेडेंशियल इस्तेमाल करें। अनुरोधकर्ता के प्रकार और एंडपॉइंट की जाँच उसी कॉलबैक को किसी वेबसाइट की प्रमाणीकरण चुनौती पर लापरवाही से प्रॉक्सी खाता देने से रोकती है।

जाँचें कि प्रमाणीकरण का कौन सा चरण विफल हो रहा है

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 हेडर स्वचालित प्रमाणक का प्रवाह बदलता है, इसलिए कॉलबैक का व्यवहार उदाहरण से अलग होने पर कस्टम हेडर जाँचें।