Какой код состояния http должен использоваться, чтобы сообщить клиенту, что время сеанса истекло?

На веб-странице он использует диспетчер соединений / источник данных YUI для отправки запросов AJAX на сервер, если сеанс (который содержит информацию о том, прошел ли пользователь аутентификацию) уже истек, те ответы ajax, которые могут быть просмотрены только аутентифицированными пользователи должны возвращать код состояния http, сообщая клиенту, что время сеанса уже истекло, затем клиент либо просто перенаправляет его на страницу входа в систему, либо спрашивает его, хочет ли он продлить сеанс.

Мой вопрос в том, что в этой ситуации какой код состояния http наиболее подходит, чтобы сообщить клиенту, что время сеанса истекло?

Список кодов состояния HTTP из вики

Лучшее, что я могу предложить, - это код состояния HTTP 401 с заголовком WWW-Authenticate.

Проблема с запросами 403 - это RFC 2616. говорится: «Авторизация не поможет, и запрос НЕ ДОЛЖЕН повторяться». (т.е. не имеет значения, аутентифицированы вы или нет, вы никогда не получите доступ к этому ресурсу).

Проблема с запросом 401 заключается в том, что в нем говорится, что они «ДОЛЖНЫ включать поле заголовка WWW-Authenticate». Как кто-то заметил, использование настраиваемого значения в заголовке WWW-Authenticate не является нарушением спецификации.

Я не вижу причин в RFC 2617, почему статус HTTP 401 в сочетании с настраиваемым заголовком WWW-Authenticate вроде этого не подходит:

WWW-Authenticate: MyAuthScheme realm="http://example.com"

Спецификация oAuth на самом деле, кажется, делает именно это, поскольку они рекомендуют это (хотя, на мой взгляд, они имеют странную интерпретацию RFC):

WWW-Authenticate: OAuth realm="http://server.example.com/"

Это не выглядит специально САНКЦИОННЫМ RFC, но я на самом деле не вижу, что это запрещено им (похоже, это не противоречит каким-либо условиям ДОЛЖЕН или НЕ ДОЛЖЕН, ДОЛЖЕН или НЕ ДОЛЖЕН).

Я бы хотел, чтобы был более конкретный код состояния HTTP для тайм-аутов и таких вещей, как недействительные токены CSRF, чтобы это было яснее.

Я бы рекомендовал HTTP 401.

В то время как 403 в основном говорит: «Тебе не разрешено, уходи и не возвращайся», 401 говорит: «Мы не знаем, разрешено тебе или нет, потому что ты не принес свой документ. возьми и попробуй еще раз. "

Сравните определения Википедии :

HTTP 403 - запрос был законным, но сервер отказывается отвечать на него.

HTTP 401 - аналогичен 403 Forbidden, но специально для использования, когда аутентификация возможна, но не удалась или еще не была предоставлена.

Насчет 419 - нестандартно, но описание в Википедии вроде подходит:

419 Тайм-аут аутентификации

Не являющийся частью стандарта HTTP, 419 Authentication Timeout означает, что срок действия ранее действующей аутентификации истек. Он используется как альтернатива 401 Unauthorized, чтобы отличать от других аутентифицированных клиентов, которым отказано в доступе к определенным ресурсам сервера.

Я считаю, что соответствующий код будет 403 / Запрещено. Нет ничего, что напрямую связано с сессиями.

Правда в том, что стандартного кода состояния HTTP для тайм-аута сеанса не существует. Сеансы реализуются на уровне приложений, а не на транспортном уровне HTTP.

Существует собственный код состояния, который Microsoft использует для тайм-аута сеанса: 599, или просто создайте свой собственный код состояния в диапазоне 5xx.

Из вики-страницы с кодами состояния:

599 Ошибка тайм-аута сетевого подключения (Неизвестно) Этот код состояния не указан ни в каких RFC, но используется прокси-серверами Microsoft Corp. HTTP для сигнализации о тайм-ауте сетевого подключения за прокси-сервером для клиента перед прокси.

Я использую настраиваемый код состояния 599 для тайм-аута сеанса, а затем проверяю его в ответе AJAX.

Согласно ссылке на Википедию кодов статуса Http, предоставленной выше Bobo:

440 Login Timeout (Microsoft)

    A Microsoft extension. Indicates that your session has expired.

Когда вы публикуете ссылку, в этой ссылке я обнаружил этот код состояния HTTP 440 . вы можете использовать код состояния 440 HTTP для истекшего сеанса.

440 Время ожидания входа в систему

 The client's session has expired and must log in again.

401 Unauthorized мы можем использовать, когда учетные данные пользователя неверны. или токен аутентификации, переданный в заголовке, недействителен.

403 Запрещено, мы можем использовать это, когда у пользователя нет определенного разрешения для запрашиваемого ресурса.

Так что, на мой взгляд, мы должны использовать 440 Login Time-out .

Технически принятый ответ, конечно, правильный: если вы уже точно знаете, что собираетесь не выполнить запрос, и спрашиваете, какой код ошибки возвращать, тогда HTTP 401 «Неавторизованный (не прошедший проверку подлинности)» является подходящим, чтобы запросить повторную аутентификацию.

Но прежде всего спросите себя: следует ли отклонять запрос?

Учтите, что пользователь может просто посещать общедоступную страницу вашего веб-сайта, и в этом случае вы собираетесь шлепнуть его по лицу с надписью «Неавторизовано!» сообщение и требуя от них повторной аутентификации, чтобы увидеть страницу, которую они обычно могли бы видеть без аутентификации. Это не круто.

Мой совет - игнорировать тот факт, что токен сеанса неизвестен, и просто приступить к созданию нового токена сеанса и создать для него новый сеанс. Первоначальное состояние сеанса, конечно же, будет «еще не аутентифицировано», поэтому, если пользователь пытается получить доступ к непубличной странице, то страница будет следить за тем, чтобы он получил HTTP 401 «Неавторизовано (не аутентифицировано). "и должны пройти аутентификацию. Но если пользователь попадает на публичную страницу, он ничего не заметит.

Я бы использовал ответ перенаправления 302 с заголовком «Location», указывающим путь к ресурсу, например «/ auth-required»

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

Для запросов, отличных от Ajax, я использую перенаправление 302.

Для запросов Ajax я использую 200 для известных ошибок. Таким образом я могу воспользоваться объектом данных. Я считаю, что с объектом данных легче работать, чем разбирать jqXHR для получения информации. И тогда мне не нужно беспокоиться о том, какой код состояния HTTP попытаться переназначить для моей ситуации.

Пример jQuery:

$.ajax({
    //send data to server
})
.done(function(data, textStatus, jqXHR) {
    if (data.success) {
        //then process return data
    }
    else {
        //get error type or message from data object
        //could use custom error codes
    }
})
.fail(function(jqXHR, textStatus, errorThrown) {
    //handle unknown errors
});

Код 408. "Тайм-аут запроса" кажется идеальным - RFC 2616 объясняет, что это означает

Клиент не отправил запрос в течение времени, которое сервер был готов ждать.

т.е. именно «тайм-аут», как вам и нужно!