Запит, що успішно проходить через проксі, доводить, що ця операція була дозволена. Але він може не доводити, що пароль перевірили заново: призначення може бути виключене або з'єднання вже автентифіковане.

Для перевірки операції використовуйте свою контрольовану кінцеву точку з відомою невеликою відповіддю та політикою доступу, якій має відповідати обліковий запис:

curl --proxy http://proxy.example:8080   --proxy-anyauth --proxy-user 'USER:PROXY_PASSWORD'   https://probe.example/status

Кінцева точка й обліковий запис — заповнювачі. Це проміжні облікові дані, окремі від будь-якого входу до призначення.

Тримайте стадію відповіді та виклик разом. 407 може почати або продовжити узгодження, повідомити про непідтримувані методи чи відхилити обліковий запис. 403 може означати відмову за політикою, а пізніша помилка сайту може йти після успішного входу через проксі.

Для свіжої валідації облікового запису використовуйте підтримувану оператором перевірку або журнали автентифікованої особи. На власному проксі дані бекенду дозволяють відрізнити справжню валідацію від анонімно дозволеного запиту. Під час зміни пароля враховуйте вікно кешованої валідації, вирішуючи, чи старі дані мали перестати працювати. Для Squid 6.13 Basic credentialsttl керує вікном кешу валідації.

Схожі статті