प्रॉक्सी प्रमाणीकरण के बिना एक Squid गंतव्य की अनुमति दें

एक निगरानी पृष्ठ को प्रॉक्सी लॉगिन के बिना काम करना चाहिए। स्पष्ट नियम http_access allow status_site है। प्रमाणीकरण से पहले रखा जाए, तो यह उन क्लाइंट्स को भी अपवाद दे सकता है जिन्हें आप कभी सेवा देने का इरादा नहीं रखते थे।

Squid 6 या 7 के लिए, अपवाद की शर्तें साथ रखें। मौजूदा प्रबंधन, असुरक्षित पोर्ट, CONNECT और स्थानीय-सेवा सुरक्षाओं के बाद, संबंधित भाग ऐसा दिख सकता है:

acl office_clients src 192.0.2.0/24
acl status_site dstdomain status.example.net
acl signed_in proxy_auth REQUIRED

http_access allow office_clients status_site
http_access allow office_clients signed_in
http_access deny all

नेटवर्क और होस्टनाम प्लेसहोल्डर हैं। प्रमाणीकरण को अब भी अपना मौजूदा हेल्पर कॉन्फ़िगरेशन चाहिए। यह किसी एक्सेस नीति का अपवाद भाग है, पूरा प्रॉक्सी कॉन्फ़िगरेशन नहीं।

पहली पंक्ति चुने गए क्लाइंट्स को लॉगिन ACL का मूल्यांकन किए बिना उस गंतव्य तक अनुमति देती है। अगली पंक्ति उन क्लाइंट्स को अन्यत्र केवल प्रमाणीकरण के बाद अनुमति देती है। पहले की व्यापक अनुमतियाँ या बाद के वैकल्पिक मार्ग परिणाम बदल सकते हैं, इसलिए शामिल फ़ाइलों सहित पूरी क्रमबद्ध नीति पढ़ें।

केवल प्रॉम्प्ट से बचने के लिए अपवाद को गंतव्य-पोर्ट सुरक्षाओं के ऊपर न ले जाएँ। अनपेक्षित पोर्ट पर अधिकृत साइट अब भी एक अलग मार्ग है। यह भी तय करें कि सटीक होस्ट या उसके सबडोमेन योग्य होने चाहिए, अनावश्यक रूप से चौड़ा प्रत्यय जोड़ने के बजाय।

होस्टनाम अपवाद मेल खाते गंतव्य को कवर करता है, उसके पृष्ठ द्वारा लोड होने वाली हर निर्भरता को नहीं। रीडायरेक्ट और तृतीय-पक्ष संपत्तियाँ वैध रूप से सामान्य लॉगिन आवश्यकता का सामना कर सकती हैं।

सादे HTTP के लिए, प्रॉक्सी जहाँ उपयुक्त हो अधिक सूक्ष्म URL जानकारी का उपयोग कर सकता है। सामान्य HTTPS CONNECT अनुरोध पृष्ठ का पथ उजागर नहीं करता, इसलिए पूरे होस्ट के टनल अपवाद से 'केवल एक पृष्ठ' का नियम नहीं निकाला जा सकता।