Squid-bufring av eksterne ACL-er: hvorfor hjelperen ikke kalles hver gang
Design Squid-hjelpere for eksterne ACL-er rundt vedvarende prosesser, hurtiglagerøkler for beslutninger og et uttrykkelig krav om autorisasjonens ferskhet.
En hjelper som logger én forespørsel og deretter blir stille, kan være normalt. Squid kan evaluere en regel ved hjelp av et bufret ekstern-ACL-resultat uten å sende hjelperen enda en forespørsel.
Definer først den gjenbrukbare beslutningen. «Kan denne kontoen bruke proxyen?» krever andre innganger enn «Kan denne kontoen nå denne destinasjonen?» Det utvidede ekstern-ACL-formatet danner hurtiglagerøklen. Hvis hjelperen avgjør etter brukernavn og destinasjon, men øklen bare inneholder brukernavnet, kan en bufret godkjenning gjelde bredere enn tiltenkt. Ta med hver inngang som endrer svaret, og unngå detaljer som bare splitter likeverdige beslutninger.
Velg deretter ferskhet. Positive ttl og negative_ttl styrer samsvarende og ikke-samsvarende resultater; grace kan starte en oppdatering før en oppføring utløper. Bestem hvor lenge en tilbakekalt kontos bufrende godkjenning kan påvirke senere beslutninger. Ingen av disse innstillingene autoriserer en etablert CONNECT-tunnel på nytt for hver byte eller interne HTTPS-forespørsel. Hvis hjelperen håndhever en trafikkvot, kan tillatte overføringer fortsette etter at saldoen endres.
Hjelperen er en vedvarende protokolldeltaker, ikke nødvendigvis en ny skriptprosess for hver forespørsel. Hold den klar for påfølgende forespørselslinjer og send hvert svar raskt. Legg diagnostikk på en annen kanal. Når samtidighet er aktivert, returner den tilsvarende oppgitte kanalidentifikatoren.
Til slutt, definer trege, utilgjengelige og interne feilutfall, og la den omkringliggende ACL-rekkefølgen produsere dem. Designet er komplett når både spesifisiteten og den tillatte alderen til et gjenbrukbart svar samsvarer med tilgangskravet.