Squid ārējo ACL kešošana: kāpēc palīgs netiek izsaukts katru reizi
Projektējiet Squid ārējos ACL palīgus ap pastāvīgiem procesiem, lēmumu kešatmiņas atslēgām un skaidru autorizācijas svaiguma prasību.
Palīgs, kas reģistrē vienu pieprasījumu un pēc tam apklust, var būt normāli. Squid var novērtēt noteikumu, izmantojot kešatmiņā saglabātu ārējā ACL rezultātu, nesūtot palīgam jaunu vaicājumu.
Vispirms definējiet atkārtoti lietojamo lēmumu. “Vai šis konts drīkst izmantot starpniekserveri?” prasa citus ievaddatus nekā “Vai šis konts var sasniegt šo galamērķi?” Paplašinātais ārējā ACL formāts veido kešatmiņas atslēgu. Ja palīgs izlemj pēc lietotājvārda un galamērķa, bet atslēga satur tikai lietotājvārdu, kešatmiņā saglabātā atļauja var tikt piemērota plašāk, nekā paredzēts. Iekļaujiet katru atbildi mainošo ievadi un izvairieties no detaļām, kas tikai sadala līdzvērtīgus lēmumus.
Pēc tam izvēlieties svaigumu. Pozitīvie ttl un negative_ttl pārvalda atbilstošus un neatbilstošus rezultātus; grace var sākt atsvaidzināšanu pirms ieraksta termiņa beigām. Izlemiet, cik ilgi atsauktā konta kešatmiņā saglabātā atļauja drīkst ietekmēt vēlākus lēmumus. Neviens no šiem iestatījumiem atkārtoti neautorizē izveidotu CONNECT tuneli katram baitam vai iekšējam HTTPS pieprasījumam. Ja palīgs piemēro trafika kvotu, atļautie pārsūtījumi var turpināties pēc bilances maiņas.
Palīgs ir pastāvīgs protokola dalībnieks, nevis obligāti jauns skripta process katram pieprasījumam. Turiet to gatavu secīgām vaicājumu rindām un nosūtiet katru atbildi nekavējoties. Diagnostiku novietojiet citā kanālā. Ja paralēlisms ir iespējots, atgrieziet atbilstošo nodrošināto kanāla identifikatoru.
Visbeidzot, definējiet lēnu, nepieejamu un iekšējas kļūdas iznākumu un panāciet, lai apkārtējā ACL secība tos radītu. Dizains ir pabeigts, kad gan atkārtoti lietojamās atbildes specifiskums, gan atļautais vecums atbilst piekļuves prasībai.