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

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

С помощью протокола HTTP Basic/Digest сервер отправляет заголовок ответа 401 Unauthorized. Однако, согласно HTTP/1.1 RFC:

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

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

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

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

Ответ 1

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

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

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

Ответ 2

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

Ответ 3

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

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

GET /login -> 200

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

GET /secured -> 401 with WWW-Authenticate header

Когда аутентификация является сеансом на основе cookie, у вас уже есть файл cookie (если это не так, вы получите его с заголовком set-cookie при запросе страницы), но этот файл cookie не говорит вам, что вы разрешено доступ к uri /secured. Поэтому, если вы попытаетесь получить доступ к этому 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

Ответ 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 лучше использовать 400.

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

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

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

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

11.2. 422 Непроцессная организация

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

RFC4918