ज्ञात एंडपॉइंटसाठी प्रीएम्प्टिव्ह Basic प्रॉक्सी प्रमाणीकरण
प्रीएम्प्टिव्ह Basic प्रॉक्सी प्रमाणीकरण स्थिर एंडपॉइंटसाठी कधी योग्य आहे हे ठरवा आणि हा निर्णय अनियंत्रित मार्गांसाठी क्रेडेन्शियल नियम होऊ देऊ नका.
आव्हानाची पहिली वाट पाहणारा क्लायंट प्रॉक्सीने विचारेपर्यंत थांबतो. प्रीएम्प्टिव्ह Basic क्लायंटला निवडलेला एंडपॉइंट आधीच माहीत असतो आणि तो आपल्या पहिल्या लागू विनंतीसोबत क्रेडेन्शियल पाठवतो. ती देवघेव काढून टाकणे उपयुक्त ठरू शकते. तरीही हा संकेतशब्द कुठे जातो याचा निर्णयच असतो.
ऑप्टिमायझेशनपूर्वी एंडपॉइंट ओळखा
ज्ञात प्रमाणीकरण धोरण असलेला स्थिर खाजगी प्रॉक्सी हा अपरिचित मध्यस्थ निवडू शकणाऱ्या राउटिंग स्तरापेक्षा स्पष्ट बाब आहे. खाते अपेक्षित प्रॉक्सी ओळख आणि प्रोटोकॉलला जोडा. प्रत्येक आव्हानाला एकाच कंपनीच्या संकेतशब्दाने उत्तर देणारा सामान्य callback बनवू नका.
Basic खात्याचे base64 निरूपण वाहून नेते, एन्क्रिप्टेड पुरावा नाही. प्रॉक्सी श्रोत्यापर्यंत TLS ही संकेतस्थळाच्या HTTPS सत्रापेक्षा वेगळी कनेक्शन निवड आहे. संकेतस्थळाचा HTTPS बोगदा एन्क्रिप्शन नसलेल्या क्लायंट-ते-प्रॉक्सी कनेक्शनवर पाठवलेल्या Basic क्रेडेन्शियलचे मागे जाऊन संरक्षण करत नाही. खाजगी LAN हे स्थान आहे, एन्क्रिप्शन गुणधर्म नाही.
यांत्रिकी विशिष्ट ठेवा
प्रीएम्प्टिव्ह Basic हा Digest, NTLM किंवा Negotiate साठी सार्वत्रिक शॉर्टकट नाही. त्या यांत्रिकींना स्वतःच्या देवघेवीच्या अटी आहेत. समर्थित स्कीम शोधणारा क्लायंट कायदेशीरपणे अतिरिक्त व्यवहार करू शकतो.
निवडलेल्या लायब्ररीचा प्रॉक्सी-प्रमाणीकरण इंटरफेस वापरा, नंतर प्रत्यक्ष स्कीम आणि व्याप्ती तपासा. गंतव्य पूर्व-प्रमाणीकरणाची सेटिंग प्रॉक्सी हातमिळवणी नियंत्रित करू शकत नाही. विद्यमान प्रमाणित कनेक्शन नवीन कनेक्शन आव्हान करेल का हे देखील लपवू शकते.
संपूर्ण क्रिया तुलना करा: देवघेवींची संख्या, पूर्ण होण्याची वेळ, आवश्यक वाहतूक संरक्षण आणि प्रॉक्सी बदलल्यावरचे वर्तन. स्वच्छ लॉग तेव्हाच उपयुक्त ठरतो जेव्हा अनुप्रयोग अजूनही इच्छित मध्यस्थाशी प्रमाणीकरण करतो आणि ती व्यवस्था प्रस्थापित होऊ शकत नाही तेव्हा थांबतो.