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 वेबसाइटच्या प्रमाणीकरण आव्हानाला निष्काळजीपणे प्रॉक्सी खाते देत नाही.

प्रमाणीकरणाचा कोणता टप्पा अयशस्वी होतो ते तपासा

सामान्य HTTP प्रॉक्सी वापर आणि CONNECT टनेलसाठी JDK मध्ये निष्क्रिय प्रमाणीकरण योजनांची वेगवेगळी सेटिंग आहेत. संबंधित नावे jdk.http.auth.proxying.disabledSchemes आणि jdk.http.auth.tunneling.disabledSchemes आहेत.

त्यामुळे HTTP ट्रॅफिकचे प्रमाणीकरण यशस्वी होऊनही त्याच प्रॉक्सीमधून HTTPS टनेल अयशस्वी होऊ शकते. दुसऱ्या मशीनवर तेच प्रभावी डीफॉल्ट असतील असे गृहीत न धरता रनटाइमची conf/net.properties आणि उपयोजन धोरण तपासा.

निष्क्रिय योजनांची यादी जागतिक पातळीवर रिकामी करणे हा प्रॉक्सी दुरुस्तीचा सार्वत्रिक उपाय नाही. एन्क्रिप्शन नसलेल्या HTTP प्रॉक्सीला पाठवलेली Basic प्रवेशमाहिती गंतव्याशी नंतर तयार होणाऱ्या TLS जोडणीने सुरक्षित होत नाही. बदल मंजूर करण्याआधी प्रॉक्सीचा ट्रान्सपोर्ट, प्रमाणीकरण पद्धत आणि उपयोजन धोरण तपासा.

JDK च्या अंगभूत प्रमाणीकरणाचे दस्तऐवजीकृत वर्तनही प्रॉक्सी जाहीर करते त्या प्रत्येक योजनेच्या समर्थनाची हमी देत नाही. हाताने दिलेला Authorization किंवा Proxy-Authorization हेडर स्वयंचलित प्रमाणकाचा प्रवाह बदलतो; म्हणून callback चे वर्तन उदाहरणापेक्षा वेगळे असल्यास कस्टम हेडर तपासा.