પ્રોક્સી પ્રમાણીકરણ વિના એક 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 વિનંતી પૃષ્ઠનો માર્ગ ઉજાગર કરતી નથી, તેથી 'ફક્ત એક પૃષ્ઠ' નિયમ હોસ્ટ-વ્યાપી ટનલ અપવાદમાંથી અનુમાન કરી શકાતો નથી.