Squid išorinių ACL talpinimas podelyje: kodėl pagalbininkas kviečiamas ne kiekvieną kartą
Projektuokite Squid išorinius ACL pagalbininkus pagal nuolatinius procesus, sprendimų podėlio raktus ir aiškų autorizacijos šviežumo reikalavimą.
Pagalbininkas, įrašantis vieną užklausą ir nutylantis, gali būti normalus. Squid gali įvertinti taisyklę naudodamas podėlyje saugomą išorinio ACL rezultatą, nesiųsdamas pagalbininkui naujos užklausos.
Pirmiausia apibrėžkite daugkartinį sprendimą. „Ar ši paskyra gali naudoti tarpinį serverį?“ reikalauja kitų įvesties duomenų nei „Ar ši paskyra gali pasiekti šią paskirties vietą?“ Išplėstinis išorinio ACL formatas sudaro podėlio raktą. Jei pagalbininkas sprendžia pagal vartotojo vardą ir paskirties vietą, bet rakte yra tik vartotojo vardas, podėlyje saugomas leidimas gali būti taikomas plačiau, nei numatyta. Įtraukite kiekvieną atsakymą keičiantį įvestį ir venkite detalių, kurios tik suskaido lygiaverčius sprendimus.
Tada pasirinkite šviežumą. Teigiami ttl ir negative_ttl valdo atitinkančius ir neatitinkančius rezultatus; grace gali pradėti atnaujinimą prieš įrašo galiojimo pabaigą. Nuspręskite, kiek ilgai atšauktos paskyros podėlyje saugomas leidimas gali paveikti vėlesnius sprendimus. Nė vienas iš šių nustatymų iš naujo neautorizuoja nustatyto CONNECT tunelio kiekvienam baitui ar vidinei HTTPS užklausai. Jei pagalbininkas taiko srauto kvotą, leidžiami perdavimai gali tęstis pasikeitus likučiui.
Pagalbininkas yra nuolatinis protokolo dalyvis, o ne būtinai naujas scenarijaus procesas kiekvienai užklausai. Laikykite jį paruoštą nuoseklioms užklausų eilutėms ir kiekvieną atsakymą siųskite nedelsdami. Diagnostiką perkelkite į kitą kanalą. Kai lygiagretumas įjungtas, grąžinkite atitinkamą pateiktą kanalo identifikatorių.
Galiausiai apibrėžkite lėto, nepasiekiamo ir vidinės klaidos rezultatus ir užtikrinkite, kad juos sukurtų aplinkinė ACL tvarka. Dizainas baigtas, kai ir daugkartinio atsakymo specifiškumas, ir leidžiamas amžius atitinka prieigos reikalavimą.