Testowanie danych uwierzytelniających proxy: sukces żądania a świeża walidacja
Użyj kontrolowanego celu, a następnie odróżnij dozwolone żądanie od świeżej weryfikacji podanego hasła proxy.
Żądanie, które przechodzi przez proxy, dowodzi, że ta operacja była dozwolona. Nie musi jednak dowodzić, że hasło sprawdzono od nowa: cel może być wyłączony albo połączenie jest już uwierzytelnione.
Do sprawdzenia operacji użyj własnego kontrolowanego punktu końcowego ze znaną małą odpowiedzią i polityką dostępu, którą konto powinno spełniać:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user 'USER:PROXY_PASSWORD' https://probe.example/statusPunkt końcowy i konto to placeholdery. To poświadczenia pośredniczące, oddzielone od każdego logowania w celu.
Trzymaj razem etap odpowiedzi i wyzwanie. 407 może rozpocząć lub kontynuować negocjacje, zgłosić nieobsługiwane metody albo odrzucić konto. 403 może oznaczać odmowę zgodnie z polityką, a późniejszy błąd witryny może nastąpić po udanym logowaniu przez proxy.
Do świeżej walidacji konta użyj obsługiwanego przez operatora sprawdzenia konta lub dzienników uwierzytelnionej tożsamości. We własnym proxy dowody z backendu mogą odróżnić rzeczywistą walidację od żądania dozwolonego anonimowo. Przy zmianach hasła uwzględnij okno walidacji w pamięci podręcznej, decydując, czy stare poświadczenie powinno przestać działać. W Squid 6.13 Basic credentialsttl kontroluje okno pamięci podręcznej walidacji.