Правильный код статуса HTTP для формы входа?

Question

Я использую аутентификацию для приложения и использую подключаемую систему с «методами аутентификации».Это позволяет мне реализовать как HTTP Basic, так и аутентификацию на основе HTML.

При аутентификации HTTP Basic / Digest сервер отправляет заголовок ответа 401 Unauthorized.Однако согласно HTTP / 1.1 RFC :

Ответ ДОЛЖЕН включать поле заголовка WWW-Authenticate (раздел 14.47), содержащее запрос, применимый к запрашиваемому ресурсу.

Поскольку я не знаю ни одного html-заголовка WWW-Authenticate, отправка 401 с HTML-формой входа кажется неуместной.Есть ли альтернатива этому?Я хочу разработать свое приложение RESTful способом.

Какой правильный код статуса HTTP (и заголовки) для формы входа на основе HTML?И какой правильный код при сбое входа в систему?

Примечание : меня не интересует дайджест-аутентификация.

Answer 1

Для HTML, я думаю, вы должны ответить 400.

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

HTML не всегда допускает чистое использование API RESTful, поэтому вполне нормально срезать углы тут и там, но, возможно, есть лучший способя не вижу в этом конкретном случае.

Answer 2

А как насчет этого?

При запросе формы входа, которая является общедоступной страницей, вы получаете то, что хотите, поэтому это код состояния 200:

GET /login -> 200

При запросе настраница, для которой требуется аутентификация на уровне http, которую вы не инициировали (базовый http, ssl-сертификат и т. д.), приложение должно сообщить самому браузеру, что ему нужно инициировать эту аутентификацию для вас:

GET /secured -> 401 with WWW-Authenticate header

Когда аутентификация является сеансом на основе файлов cookie, у вас уже есть файл cookie (если это не так, вы получите файл с заголовком set-cookie при запросе страницы), но этот файл cookie не говорит о том, что вам разрешенодоступ к /secured URI.Поэтому, если вы попытаетесь получить доступ к этому URI, вы должны получить статус «403 запрещено».Тогда действие «войти в систему» ​​- это не более, чем просто изменить состояние приложения с помощью запроса POST, чтобы приложение предоставило доступ к этому cookie, поэтому ...

Войдите в систему с неверными учетными данными:

GET /secured -> 403 with HTML login form (with action="/login")
POST /login -> 403 with HTML login form, displaying errors

Войдите в систему с хорошими учетными данными, но недостаточно прав:

GET /secured -> 403 with HTML login form (with action="/login")
POST /login -> 403 with HTML page saying "I know you are John, but you can't get this page"

Войдите с хорошими учетными данными и достаточными разрешениями:

GET /secured -> 403 with HTML login form (with action="/login")
POST /login -> 302 (temporary redirection to /secured)
GET /secured -> 200

Answer 3

Это сложный вопрос, во многом из-за того, что наиболее известными HTTP-клиентами, используемыми людьми, являются браузеры.Согласно RFC, заголовок WWW-Authenticate может содержать что угодно.Базовая и дайджест-аутентификация - это всего лишь два примера дальнейших стандартизированных механизмов запроса / ответа.Вы можете просто указать задачу, например html-form id=foo, и вернуть 401 вместе с формой HTML.Также напомним из спецификации, что в одном и том же заголовке WWW-Authenticate можно указать несколько задач, но у меня нет опыта интенсивного тестирования браузеров с различными схемами.

Answer 4

@ 2016-02-17 Обновлено

Статус login form http должен быть 200 OK.

Статус error http лучше использовать 401 Unauthorized.(Имя может быть запутано, 401 относится к аутентификации. RFC7235

3.1. 401 Несанкционированный

Код состояния 401 (Несанкционированный) указывает, что запрос имеетне был применен, поскольку ему не хватает действительных учетных данных аутентификации для целевого ресурса. Сервер, генерирующий ответ 401, ДОЛЖЕН отправить поле заголовка WWW-Authenticate (раздел 4.1), содержащее как минимум одну проблему, применимую к целевому ресурсу.

Если в запрос включены учетные данные для проверки подлинности, то в ответе 401 указывается, что для этих учетных данных было отказано в авторизации. Пользовательский агент МОЖЕТ повторить запрос с новым или замененным полем заголовка авторизации (раздел 4.2). Если ответ 401содержит ту же задачу, что и предыдущий ответ, и пользовательский агент уже предпринял попытку аутентификации хотя бы один раз, тогда пользовательскому агенту СЛЕДУЕТ представить приложенное представление пользователю, поскольку оно обычно содержит соответствующую диагностическую информацию.

Если вы хотите обработать, если у вас нет прав, вам может понадобиться 403 Forbidden [RFC7231]

HTTP 422 используется для WebDAV, но значение может соответствовать потребностям.(Не рекомендуется для большинства случаев)

Для получения дополнительной информации см. Комментарий Cássio Mazzochi Molin ниже.

---

@ 2016-02-12 Обновлено (Это ссылка на принятый ответ.)

Статус login form http должен быть 200.

Статус error http лучшеuse 400.

HTTP 422 используется для WebDAV, но значение может соответствовать потребностям.HTTP 401 для авторизации.И не подходит для аутентификации.

---

@ 2016-02-12 Оригинал

HTTP 422 теперь лучше, чем 400/401. HTTP 422 - альтернативный выбор.

Потому что это означает, что сервер понимает данные, но не является корректным для части данных.т.е. он может показать клиенту, что имя пользователя / пароль неверны.

11.2.422 Unprocessable Entity

Код состояния 422 (Unprocessable Entity) означает, что сервер понимает тип содержимого объекта запроса (следовательно, код состояния 415 (Unsupported Media Type) неуместен) и синтаксис объекта запросаявляется правильным (таким образом, код состояния 400 (неверный запрос) не подходит), но не смог обработать содержащиеся в нем инструкции.Например, это условие ошибки может возникнуть, если тело запроса XML содержит правильно сформированные (т. Е. Синтаксически правильные), но семантически ошибочные инструкции XML.

RFC4918