Buforowanie zewnętrznych ACL w Squidzie: dlaczego pomocnik nie jest wywoływany za każdym razem
Projektuj pomocników zewnętrznych ACL Squida wokół trwałych procesów, kluczy pamięci podręcznej decyzji i wyraźnego wymogu świeżości autoryzacji.
Pomocnik, który zapisuje jedno żądanie i potem milknie, może być normalny. Squid może ocenić regułę na podstawie zbuforowanego wyniku zewnętrznego ACL, nie wysyłając pomocnikowi kolejnego zapytania.
Najpierw zdefiniuj decyzję wielokrotnego użytku. „Czy to konto może używać proxy?” wymaga innych danych wejściowych niż „Czy to konto może dotrzeć do tego celu?” Rozszerzony format zewnętrznego ACL tworzy klucz pamięci podręcznej. Jeśli pomocnik decyduje według nazwy użytkownika i celu, ale klucz zawiera tylko nazwę użytkownika, zbuforowana zgoda może obowiązywać szerzej, niż zamierzono. Uwzględnij każde dane wejściowe zmieniające odpowiedź i unikaj szczegółów, które tylko rozdrobniją równoważne decyzje.
Następnie wybierz świeżość. Dodatnie ttl i negative_ttl rządzą wynikami zgodnymi i niezgodnymi; grace może rozpocząć odświeżanie przed wygaśnięciem wpisu. Zdecyduj, jak długo zbuforowana zgoda unieważnionego konta może wpływać na późniejsze decyzje. Żadne z tych ustawień nie autoryzuje ponownie ustanowionego tunelu CONNECT dla każdego bajtu czy wewnętrznego żądania HTTPS. Jeśli pomocnik egzekwuje limit ruchu, dozwolone transfery mogą być kontynuowane po zmianie salda.
Pomocnik jest trwałym uczestnikiem protokołu, a niekoniecznie nowym procesem skryptu dla każdego żądania. Utrzymuj go gotowym na kolejne linie zapytań i wysyłaj każdą odpowiedź niezwłocznie. Diagnostykę umieść na innym kanale. Przy włączonej współbieżności zwróć odpowiedni dostarczony identyfikator kanału.
Na koniec zdefiniuj wyniki wolny, niedostępny i błąd wewnętrzny oraz spraw, aby otaczająca kolejność ACL je wytwarzała. Projekt jest kompletny, gdy zarówno swoistość, jak i dozwolony wiek odpowiedzi wielokrotnego użytku odpowiadają wymaganiu dostępu.