ज्ञात एंडपॉइंट के लिए प्रीएम्प्टिव Basic प्रॉक्सी प्रमाणीकरण
तय करें कि प्रीएम्प्टिव Basic प्रॉक्सी प्रमाणीकरण कब स्थिर एंडपॉइंट के लिए उपयुक्त है, और इस निर्णय को मनमाने मार्गों के लिए क्रेडेंशियल नियम बनने से रोकें।
चुनौती-पहले वाला क्लाइंट प्रॉक्सी के पूछने की प्रतीक्षा करता है। प्रीएम्प्टिव Basic क्लाइंट पहले से चयनित एंडपॉइंट जानता है और अपने पहले लागू अनुरोध में क्रेडेंशियल भेजता है। उस आदान-प्रदान को हटाना उपयोगी हो सकता है। यह फिर भी एक निर्णय है कि पासवर्ड कहाँ जाता है।
अनुकूलन से पहले एंडपॉइंट जानें
ज्ञात प्रमाणीकरण नीति वाला स्थिर निजी प्रॉक्सी उस रूटिंग परत से अधिक स्पष्ट मामला है जो अपरिचित मध्यस्थ चुन सकती है। खाते को अपेक्षित प्रॉक्सी पहचान और प्रोटोकॉल से बाँधें। ऐसा सामान्य callback न बनाएँ जो हर चुनौती का उत्तर एक कंपनी पासवर्ड से दे।
Basic खाते का base64 निरूपण ले जाता है, एन्क्रिप्टेड प्रमाण नहीं। प्रॉक्सी श्रोता तक TLS वेबसाइट के HTTPS सत्र से अलग कनेक्शन विकल्प है। वेबसाइट की HTTPS सुरंग बिना एन्क्रिप्शन वाले क्लाइंट-से-प्रॉक्सी कनेक्शन पर भेजे गए Basic क्रेडेंशियल को पूर्वव्यापी रूप से नहीं बचाती। निजी LAN एक स्थान है, एन्क्रिप्शन गुण नहीं।
तंत्र को विशिष्ट रखें
प्रीएम्प्टिव Basic, Digest, NTLM या Negotiate के लिए सार्वभौमिक शॉर्टकट नहीं है। उन तंत्रों की अपनी आदान-प्रदान आवश्यकताएँ हैं। समर्थित स्कीम खोजने वाला क्लाइंट वैध रूप से अतिरिक्त लेनदेन कर सकता है।
चयनित लाइब्रेरी का प्रॉक्सी-प्रमाणीकरण इंटरफ़ेस उपयोग करें, फिर प्रभावी स्कीम और दायरा जाँचें। गंतव्य पूर्व-प्रमाणीकरण की सेटिंग प्रॉक्सी हैंडशेक को नियंत्रित नहीं कर सकती। मौजूदा प्रमाणित कनेक्शन यह भी छिपा सकता है कि नया कनेक्शन चुनौती देगा या नहीं।
पूरा संचालन तुलना करें: आदान-प्रदान संख्या, पूर्ण होने का समय, आवश्यक परिवहन सुरक्षा और प्रॉक्सी बदलने पर व्यवहार। स्वच्छ लॉग केवल तब उपयोगी है जब एप्लिकेशन अभी भी इच्छित मध्यस्थ के प्रति प्रमाणित करता हो और वह व्यवस्था स्थापित न हो पाने पर रुक जाए।