O pagină de monitorizare trebuie să funcționeze fără autentificare la proxy. Regula evidentă este http_access allow status_site. Plasată înaintea autentificării, poate acorda excepția și clienților pe care nu intenționați niciodată să îi deserviți.

Pentru Squid 6 sau 7, păstrați condițiile excepției împreună. După protecțiile existente pentru administrare, porturi nesigure, CONNECT și servicii locale, partea relevantă poate arăta astfel:

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

Rețeaua și numele gazdei sunt substituenți. Autentificarea are în continuare nevoie de configurația sa existentă de helper. Aceasta este partea de excepție a unei politici de acces, nu o configurație completă de proxy.

Prima linie permite clienților selectați acea destinație fără a evalua ACL-ul de autentificare. Următoarea permite acelor clienți în altă parte numai după autentificare. Permisiunile largi anterioare sau căile alternative ulterioare pot schimba rezultatul, așa că citiți întreaga politică ordonată, inclusiv fișierele incluse.

Nu mutați excepția deasupra protecțiilor portului de destinație doar pentru a evita o solicitare. Un site autorizat pe un port neintenționat rămâne o rută diferită. De asemenea, decideți dacă gazda exactă sau subdomeniile sale ar trebui să se califice în loc să adăugați un sufix inutil de larg.

O excepție de nume de gazdă acoperă destinația potrivită, nu fiecare dependență încărcată de pagina sa. Redirecționările și resursele terțe pot întâlni în mod legitim cerința normală de autentificare.

Pentru HTTP simplu, un proxy poate folosi informații URL mai fine atunci când este adecvat. O cerere HTTPS CONNECT obișnuită nu expune calea paginii, așa că regula „o singură pagină” nu poate fi dedusă dintr-o excepție de tunel pentru întreaga gazdă.

Articole similare