चॅलेंज ओळखीवरून Java HTTP प्रॉक्सी क्रेडेन्शियल्स निवडा
खाते परत करण्यापूर्वी विनंतीकर्त्याचा प्रकार, होस्ट आणि पोर्ट जुळवा; असंबंधित सर्व्हर चॅलेंज त्या शोधाबाहेर ठेवा.
प्रत्येक HTTP प्रमाणीकरण कॉलबॅकसाठी या क्रमाने क्रेडेन्शियलचा निर्णय घ्या:
- विनंतीकर्ता प्रॉक्सी आहे, गंतव्य सर्व्हर नाही याची तपासणी करा.
- विनंती करणारे होस्ट आणि पोर्ट मंजूर प्रॉक्सी नोंदीशी जुळवा.
- त्या नोंदीचे खाते परत करा, किंवा न जुळणाऱ्या चॅलेंजसाठी कोणतेही क्रेडेन्शियल देऊ नका.
एकच बिनशर्त वापरकर्तानाव/पासवर्ड दोन प्रॉक्सींची खाती व्यक्त करू शकत नाही आणि ती दुसऱ्या प्राप्तकर्त्याकडे गळू शकतात.
Java च्या HTTP क्लायंट बिल्डरचा वापर करताना क्लायंटशी जोडलेल्या Authenticator ला प्राधान्य द्या. JVM चा डीफॉल्ट Authenticator इतर सहभागी कोडवरही परिणाम करतो.
कोणतेही होस्ट-उपनाव मॅपिंग अनियंत्रित नावे स्वीकारण्याऐवजी जाणूनबुजून परिभाषित करा. हा HTTP नमुना आहे; SOCKS समान होस्टनावावरही दुसरा अंमलबजावणी मार्ग वापरू शकतो.
निदानासाठी, चॅलेंज प्रकार आणि जुळणारा खाते ओळखकर्ता त्याच्या रहस्याशिवाय नोंदवा. यामुळे पासवर्ड लॉग न करता व्याप्तीचा निर्णय स्पष्ट होतो.