HTTP 401 - какое подходящее значение заголовка WWW-Authenticate?

В приложении, на котором я сейчас работаю, есть значение тайм-аута сеанса. Если пользователь не взаимодействовал дольше, чем это значение, на следующей странице, которую они пытаются загрузить, им будет предложено войти в систему.

Все выполненные запросы маршрутизируются через этот механизм, который включает вызовы AJAX. Первоначально мы отправляли заголовок 200 с страницей входа в систему, что приводит к некоторым проблемам с AJAX, поскольку код запускается, если отправлен ответ 200, и большинство данных, отправленных с этих вызовов RPC, - это JSON или необработанный JavaScript, который оценивается (не спросите: |).

Я предположил, что 401 лучше, так как наш парсер JSON не будет пытаться использовать страницу входа в HTML..:)

Если чтение спецификации, однако, я заметил, что поле WWW-Authenticate также должно быть отправлено.

Что хорошего для этого поля? Будет ли Application Login достаточным?

Ответы

Ответ 1

При указании базовой аутентификации HTTP мы возвращаем что-то вроде:

WWW-Authenticate: Basic realm="myRealm"

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

Очевидно, что вы не используете Basic, так как нет смысла иметь истечение сеанса при использовании Basic Auth. Я предполагаю, что вы используете некоторую форму аутентификации на основе форм.

От воспоминания, Windows Challenge Response использует другую схему и разные аргументы.

Фокус в том, что он в браузере определяет, какие схемы он поддерживает, и как он реагирует на них.

У меня возникает ощущение, что если вы используете аутентификацию на основе форм, оставайтесь на странице 200 + relogin, но добавляйте пользовательский заголовок, который браузер игнорирует, но ваш AJAX может идентифицировать.

Для действительно хорошего использования User + AJAX запустите script, чтобы вставить запрос AJAX, который заставил сеанс истек, скрыть запрос на повторную регистрацию через всплывающее окно и при успешном повторном отправке оригинального запроса AJAX и переноса как обычно.

Избегайте обмана, который просто получает script, чтобы попасть на сайт каждые 5 минут, чтобы сохранить ожидание сессии, что просто побеждает точку истечения сессии.

Другой вариант - записать запрос AJAX, но это плохой пользовательский интерфейс.

Ответ 2

Нет, вам нужно будет указать используемый метод аутентификации (обычно "Basic" ) и область аутентификации. См. http://en.wikipedia.org/wiki/Basic_access_authentication для примерного запроса и ответа.

Вы также можете прочитать RFC 2617 - Аутентификация HTTP: аутентификация основного и дайджест-доступа.

Ответ 3

Когда сеанс пользователя заканчивается, я отправляю код статуса HTTP 204. Обратите внимание, что статус HTTP 204 не содержит содержимого. На стороне клиента я делаю это:

xhr.send(null);
if (xhr.status == 204) 
    Reload();
else 
    dropdown.innerHTML = xhr.responseText;

Вот функция Reload():

function Reload() {
    var oForm = document.createElement("form");
    document.body.appendChild(oForm);
    oForm.submit();
    }