Squid-bufring av eksterne ACL-ar: kvifor hjelparen ikkje blir kalla kvar gong
Design Squid-hjelparar for eksterne ACL-ar rundt vedvarande prosessar, hurtiglagerøklar for avgjerder og eit uttrykkeleg krav om ferskleiken til autorisasjonen.
Ein hjelpar som loggar éin førespurnad og deretter blir stille, kan vere normalt. Squid kan vurdere ei regel ved hjelp av eit bufra ekstern-ACL-resultat utan å sende hjelparen endå ein førespurnad.
Definer fyrst den gjenbrukbare avgjerda. «Kan denne kontoen bruke proxyen?» krev andre inngangar enn «Kan denne kontoen nå denne destinasjonen?» Det utvida ekstern-ACL-formatet dannar hurtiglagerøkelen. Viss hjelparen avgjer etter brukarnamn og destinasjon, men økelen berre inneheld brukarnamnet, kan ei bufra godkjenning gjelde vidare enn tenkt. Ta med kvar inngang som endrar svaret, og unngå detaljar som berre splittar likeverdige avgjerder.
Vel deretter ferskleik. Positive ttl og negative_ttl styrer samsvarande og ikkje-samsvarande resultat; grace kan starte ei oppdatering før ei oppføring går ut. Avgjer kor lenge ei bufra godkjenning for ein tilbakekalla konto kan påverke seinare avgjerder. Ingen av desse innstillingane autoriserer ein etablert CONNECT-tunnel på nytt for kvar byte eller interne HTTPS-førespurnad. Viss hjelparen handhevar ein trafikkkvote, kan tillatne overføringar halde fram etter at saldoen endrar seg.
Hjelparen er ein vedvarande protokolldeltakar, ikkje nødvendigvis ein ny skriptprosess for kvar førespurnad. Hald han klar for påfølgjande førespurnadslinjer og send kvart svar raskt. Legg diagnostikk på ein annan kanal. Når samtidigheit er slått på, returner den tilsvarande oppgjevne kanalidentifikatoren.
Til slutt, definer trege, utilgjengelege og interne feilutfall, og la den omkringliggande ACL-rekkjefølgja produsere dei. Designet er komplett når både spesifisiteten og den tillatne alderen til eit gjenbrukbart svar samsvarar med tilgangskravet.