Basic Auth: почему кнопка выхода и удаление cookie не помогают

Кнопка выхода из приложения может завершить его сессию, но не обязана прекратить повторную отправку Basic Auth браузером. Удаление отдельного cookie не является универсальным сбросом HTTP-аутентификации. Сначала определите, какие слои доступа используются и что именно должна завершать кнопка, затем проверьте это в целевых браузерах.

Какой экран входа вы наблюдаете

Браузерный запрос имени и пароля и форма входа самого сайта могут относиться к разным механизмам. Иногда они стоят последовательно: внешняя HTTP-аутентификация и внутренняя сессия кабинета. Тогда слово «вышел» без уточнения слоя оставляет слишком много разных ожиданий.

В обзоре HTTP-аутентификации MDN Basic описан как передача учётной пары через соответствующий механизм заголовка Authorization. Base64 является обратимым представлением, а не шифрованием; для защиты передачи необходим HTTPS/TLS. К cookie приложения этот способ не сводится.

Почему следующий запрос снова проходит проверку

В RFC 7617, разделе о повторном использовании credentials клиенту разрешено заранее передавать соответствующее подтверждение в области защиты. Поэтому после перехода на страницу выхода приложение может снова получить запрос с данными HTTP-аутентификации.

Это не доказательство, что сервер восстановил уничтоженную сессию кабинета. Внешний слой мог быть пройден, а внутренний всё ещё должен проверять свой контекст. Разбирайте фактические запросы и результаты каждого слоя, не называя любое повторное окно страницы успешным входом во все функции.

Учебная карта выхода по слоям

Ниже модель сайта с двумя уровнями доступа. Она вымышлена и не сообщает конфигурацию реального проекта. Конкретное поведение браузера и сервера требуется проверить отдельно по выбранному контракту.

Удаление cookie и специальная очистка данных различаются

Истечение cookie внутренней сессии не равно команде очистить все HTTP-учётные данные клиента. Но нельзя делать и обратный универсальный вывод, что любые механизмы очистки cookies никогда не затрагивают Basic. У специализированных средств есть собственные правила.

Например, MDN о Clear-Site-Data описывает очистку HTTP-аутентификационных данных при поддерживаемом типе cookies. Там же указаны безопасный контекст и широкая область, включая поддомены зарегистрированного домена. Это требует проверки совместимости и последствий, а не слепого добавления общего заголовка на каждый ответ.

Такой механизм не следует приравнивать к удалению одной записи cookie скриптом. И он не заменяет серверное завершение сессии приложения. В требованиях отдельно перечислите, что должно перестать действовать на клиенте, а что — на сервере.

Почему обходные приёмы не задают надёжный выход

Не используйте адрес со встроенными неправильными учётными данными как обещанный универсальный logout. Не гарантируйте также, что закрытие одной вкладки очистит состояние во всех браузерах. Эти приёмы зависят от клиента и не дают ясного контракта завершения доступа.

Смена пароля или отзыв учётной записи тоже отвечает другой задаче: сервер перестаёт принимать прежнее подтверждение. Это может затронуть другие устройства и пользователей той же учётной записи. Не подменяйте локальный выход глобальным изменением права без соответствующего решения.

Как сформулировать ожидаемое поведение

Запишите, что должно происходить после выхода: доступ к конкретному кабинету прекращён, новая операция требует входа, другой человек на том же устройстве не получает прежний контекст. Затем сопоставьте каждое ожидание с механизмом. У одной кнопки могут быть несколько разных обязанностей.

Если нужно завершить только внутреннюю сессию, интерфейс не должен обещать забывание всех браузерных credentials. Если требуется полный повторный вход на каждом согласованном клиенте, механизм доступа выбирают и проверяют под это требование. Название кнопки не добавляет протоколу недостающего поведения.

Что проверить при двух уровнях входа

Проверьте прямой переход к защищённому действию после выхода из внутреннего кабинета. Успех внешнего Basic не должен сам по себе подтверждать действительность завершённой внутренней сессии, если по архитектуре она обязательна. Это предмет проверки доступа, а не только отображения формы.

Также проверьте повторное открытие, другую вкладку и согласованный сценарий общего устройства. Сохраняйте, какой слой прошёл, а какой отказал. Не записывайте в диагностический журнал пароль или полный Authorization: для отчёта нужны безопасные признаки и результат, а не секретная учётная пара.

Порядок приёмки выхода

1. Перечислите HTTP-аутентификацию, внутреннюю сессию и другие реально используемые уровни.
2. Опишите ожидаемый результат кнопки для каждого уровня отдельно.
3. Выберите поддерживаемый механизм и проверьте его область и совместимость.
4. В разрешённой тестовой среде проверьте повторный запрос и доступ к защищённому действию.
5. Отдельно проверьте вкладки и общий клиент без предположения об одинаковом поведении браузеров.
6. Убедитесь, что серверные проверки и клиентская очистка соответствуют обещанию интерфейса.

В статье нет настоящих credentials, выполненных атак и изменений системы доступа. Учебная карта помогает определить сценарии. Итог конкретного браузера или сервера должен быть получен проверкой, а не перенесён из случайного форумного рецепта.

Что включить в задачу по кабинету

Для аудита сайта укажите слои доступа и наблюдаемое расхождение. В разработке веб-приложения определите контракт выхода заранее. В задаче доработки приложите ожидаемый результат и безопасный сценарий приёмки.

Корректный выход — согласованное завершение нужного доступа, а не просто переход на страницу с надписью «Вы вышли». Его проверяют по следующей операции и состоянию каждого необходимого механизма.