Да, но это не очень гладко.
У вас есть специальный URL-адрес сценария (например, /logout; как и сценарий входа в систему, он должен находиться в корне веб-приложения, чтобы гарантировать, что аутентификация будет установлена направильный путь), который вместо того, чтобы требовать действительное имя пользователя / пароль, требует неверного.
Таким образом, вошедший в систему пользователь нажимает /logout, отправляя действительные учетные данные в заголовке Authorization.Ваш скрипт отвечает 401, и в браузере появляется запрос на ввод имени пользователя / пароля.Вы говорите пользователю ввести ложные значения (или, в большинстве браузеров, просто оставьте поле пустым, тоже ОК) и нажимаете ОК.Это заменяет действительные сохраненные учетные данные недействительными.Затем ваш сценарий возвращает страницу «вышли из системы» или перенаправление на домашнюю страницу, и пользователь больше не входит в систему.
(Внимание: Safari, к сожалению, сначала передает каждый HTTP-запрос без каких-либо учетных данных,только повторная попытка с сохраненными учетными данными, если он получает ответ 401. Это означает, что вы не должны принимать запрос без заголовка Authorization как нормально для сценария выхода из системы, он должен присутствовать, даже если с пустыми учетными данными в немЭто неудачное поведение также означает, что вы не можете предоставить зарегистрированной и незарегистрированной версии одной и той же страницы пользователям Safari по одному и тому же URL, и это замедляет просмотр Safari сайтов, защищенных Basic, так как каждый запрос страницыдолжно произойти дважды.)
Есть и другой способ, который иногда используется: используйте JavaScript для отправки XMLHttpRequest с фальшивой комбинацией имени пользователя и пароля (например, xhr.open('GET', '/app', true, '_', '_')).У этого есть нестандартный побочный эффект замены сохраненных учетных данных в IE и Firefox (но не в Opera; не уверен насчет других).
[Тьфу.Это боль.Неудивительно, что вместо этого все используют куки ...]