Squid-caching af ekstern ACL: hvorfor helperen ikke kaldes hver gang
Design Squid-helpers til ekstern ACL omkring vedvarende processer, cache-nøgler for beslutninger og et udtrykkeligt krav om autorisationens friskhed.
En helper, der logger én forespørgsel og derefter tier, kan være normal. Squid kan evaluere en regel ved hjælp af et cachet ekstern-ACL-resultat uden at sende helperen endnu en forespørgsel.
Definér først den genbrugelige beslutning. “Må denne konto bruge proxyen?” kræver andre input end “Må denne konto nå denne destination?” Det udvidede ekstern-ACL-format udgør cache-nøglen. Hvis helperen beslutter ud fra brugernavn og destination, men nøglen kun indeholder brugernavnet, kan en cachet godkendelse gælde bredere end tilsigtet. Medtag hvert input, der ændrer svaret, og undgå detaljer, som blot opsplitter ækvivalente beslutninger.
Vælg derefter friskhed. Positive ttl og negative_ttl styrer matchende og ikke-matchningsresultater; grace kan starte en opdatering, før en post udløber. Beslut, hvor længe en tilbagekaldt kontos cachede godkendelse må påvirke senere beslutninger. Ingen af disse indstillinger genautoriserer en etableret CONNECT-tunnel for hver byte eller indre HTTPS-forespørgsel. Hvis helperen håndhæver en trafikkvote, kan tilladte overførsler fortsætte, efter at saldoen ændres.
Helperen er en vedvarende protokol-deltager, ikke nødvendigvis en ny scriptproces for hver forespørgsel. Hold den klar til på hinanden følgende forespørgselslinjer, og send hvert svar med det samme. Læg diagnostik på en anden kanal. Når samtidighed er aktiveret, returnér det tilsvarende medsendte kanal-id.
Endelig skal du definere langsomme, utilgængelige og interne fejlresultater og få den omgivende ACL-rækkefølge til at frembringe dem. Designet er komplet, når både specificiteten og den tilladte alder af et genbrugeligt svar matcher adgangskravet.