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

Question

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

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

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

Answer 1

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

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

Проблема с 401 запросами заключается в том, что они "ДОЛЖНЫ включать поле заголовка WWW-Authenticate". * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * [1012] не нарушает спецификацию использования пользовательского значения в заголовке 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, чтобы это было понятнее.

Answer 2

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

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

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

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

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

Answer 3

Как насчет 419 - это не стандарт, но описание в Википедии , кажется, подходит:

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

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

Answer 4

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

Answer 5

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

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

Из кодов статуса Wiki:

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

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

Answer 6

Согласно ссылке на Википедию Http Status Codes , предоставленной выше Бобо:

440 Login Timeout (Microsoft)

    A Microsoft extension. Indicates that your session has expired.

Answer 7

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

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

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

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

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

Так что, по моему мнению, мы должны использовать 440 Время ожидания входа в систему .

Answer 8

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

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

Answer 9

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

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

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

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

Answer 10

Для запросов без 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
});