3proxy की HTTP और SOCKS दोनों सेवाओं पर लॉगिन आवश्यक करें

उपयोगकर्ता परिभाषित करना 3proxy का पूरा लॉगिन कॉन्फ़िगरेशन नहीं है। सेवा को एक प्रमाणीकरण विधि और उसका उपयोग करने वाला पहुँच नियम भी चाहिए। क्रम मायने रखता है क्योंकि कॉन्फ़िगरेशन संसाधित होते समय सेवा सेटिंग्स लागू होती हैं।

दो सेवाओं के लिए केवल स्थानीय उदाहरण:

users alex:CL:replace_with_a_private_password
auth strong
allow alex
proxy -i127.0.0.1 -p3128
flush
allow alex
socks -i127.0.0.1 -p1080

कॉन्फ़िगरेशन संदर्भ users, auth strong और सेवा कमांड समझाता है। CL इस उदाहरण पासवर्ड को सादे टेक्स्ट के रूप में संग्रहीत करता है। फ़ाइल को सुरक्षित रखें और परिनियोजन के लिए उपयुक्त समर्थित क्रेडेंशियल-भंडारण रूप चुनें।

क्लाइंट को सही लॉगिन आदान-प्रदान चाहिए

HTTP सेवा HTTP प्रॉक्सी प्रमाणीकरण की अपेक्षा करती है। SOCKS सेवा को SOCKS5 उपयोगकर्ता नाम और पासवर्ड प्रमाणीकरण समर्थित करने वाला क्लाइंट चाहिए। SOCKS4 क्लाइंट केवल इसलिए वह आदान-प्रदान नहीं दे सकता कि वह उसी लिसनर पोर्ट तक पहुँचता है।

strong शब्द प्रमाणीकरण मोड का नाम है, एन्क्रिप्टेड परिवहन की गारंटी नहीं। आवश्यक होने पर क्लाइंट से प्रॉक्सी तक के हिस्से को सुरक्षित रखें। गंतव्य तक HTTPS और प्रॉक्सी तक एन्क्रिप्शन अलग निर्णय बने रहते हैं।

लूपबैक बाइंडिंग इस उदाहरण को स्थानीय पहुँच तक सीमित करती हैं। दूरस्थ क्लाइंट के लिए इच्छित लिसनर और नेटवर्क नीति स्पष्ट रूप से चुनें। सार्वजनिक वाइल्डकार्ड लिसनर लॉगिन व्यवहार जाँचने का विकल्प नहीं है।

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