Fereaskje sawol in Squid-oanmelding as it juste klant-IP

In goed wachtwurd is mar de helte fan dit belied: it akkount moat ek fan ien goedkard klantadres wurkje. Yn Squid is it ferskil tusken dy eask en twa aparte yngongen om beide kontrôles op deselde tagongsregel te setten.

Oannommen dat autentikaasje al ynsteld is, lykas in Squid 6.13 NCSA-ynstelling, is it kearnbelied:

acl approved_login proxy_auth alex
acl approved_source src 192.0.2.40/32
http_access allow approved_source approved_login
http_access deny all

Brûk de boarne dy't Squid eins ûntfangt; it foarbyld is in dokumintaasje-adres. Behâld eardere beskermingen foar ûnfeilige bestimmingspoarten, lokale tsjinsten en CONNECT-ferkear. Dit fragmint lit de kombinearre betingst sjen, net in folsleine listener-konfiguraasje.

Kontrolearje de regels derboppe

In earder breed talitten kin it fersyk akseptearje foardat it de nije betingst berikt. De http_access-referinsje beskriuwt oardere oerienkomst. Lês de folsleine folchoarder, ynklusyf ynfoege bestannen.

Ien talitting foar de brûkersnamme en in oare foar de boarne fereaskje net beide. Eltse rigel kin selsstannich slagje. Dat is in oar belied.

De proxy_auth ACL is ôfhinklik fan in autentikaasjehelper. It definiearjen dêrfan is net hoe't jo de brûker oanmeitsje of it wachtwurd falidearje. Dit foarbyld is foar in eksplisite proxy waans klanten op proxy-autentikaasje-útdagings reagearje kinne.

Boarne-identiteit hat ek grinzen. Minsken efter ien NAT kinne in adres diele, en in beweegjende laptop kin fan adres feroarje. De ekstra betingst ferbreget it brûkbere netwurkplak fan it akkount; it identifisearret net betrouber in fysike kompjûter. Soargje dat dy beheining past by de reden wêrom't jo de betingst earst tafoege.