Какой код статуса HTTP нужно вернуть, если пользователь пытается войти в систему с неверным именем пользователя и паролем, но в правильном формате?
Аналогичный вопрос размещен здесь: Какой соответствующий код состояния HTTP возвращается службой REST API в случае ошибки проверки?
Ответ в ветке выше гласит: "Например, если предполагается, что URI имеет дату ISO-8601, и вы обнаружите, что она имеет неправильный формат или относится к 31 февраля, вы должны вернуть HTTP 400. То же самое, если вы ожидаете правильно сформированный XML в теле объекта, и он не может разобрать ".
Однако что произойдет, если пользователь отправит правильно отформатированные данные? Под этим я подразумеваю, что пользователь представил простую алфавитную строку / текст для имени пользователя и пароля (что совершенно верно для моего приложения). Единственная проблема заключается в том, что пароль не совпадает с именем пользователя. В этом случае 400 будет неправильным, потому что это совершенно правильный синтаксис и правильно сформированный.
401 будет неправильным (как здесь предлагается: какой код состояния HTTP, чтобы сказать, что имя пользователя или пароль были неправильными?), Потому что пользователь не пытается получить доступ к какой-либо странице, он просто пытается войти в систему и ввести данные, которые не совпадают.
Если вы посмотрите на первое сообщение, на которое я ссылался, то во втором ответе говорится, что 422 является правильным ответом (и мне он кажется правильным), однако я использую Django Rest Framework, а 422 не является частью кодов состояния (a список кодов состояния, которые являются частью DRF, можно найти здесь: http://www.django-rest-framework.org/api-guide/status-codes/)
404 также выглядит неправильно, потому что данные успешно приняты и не отклонены.
С учетом сказанного, что является действительно правильным ответом, который следует использовать?
6 ответов
Правильный код HTTP будет на самом деле 401. Из RFC:
Код состояния 401 (неавторизованный) указывает, что запрос не был применен, поскольку в нем отсутствуют действительные учетные данные аутентификации для целевого ресурса. Сервер, генерирующий ответ 401, ДОЛЖЕН отправить поле заголовка WWW-Authenticate (раздел 4.1), содержащее, по крайней мере, один запрос, применимый к целевому ресурсу.
Если в запрос включены учетные данные для проверки подлинности, то ответ 401 указывает, что для этих учетных данных было отказано в авторизации. Пользовательский агент МОЖЕТ повторить запрос с новым или замененным полем заголовка Авторизация (Раздел 4.2).
Use the appropriate status code in for a successfully handled login request with the wrong password.
Before asking "what is the correct HTTP status code", it's important to consider this question: "Should success or failure of login be reflected in the HTTP status code of the response?"
In @sjagr's answer the first part of this section is highlighted. I'm going to highlight the second part and explain why:
If the request included authentication credentials, then the 401 response indicates that authorization has been refused for those credentials. The user agent MAY repeat the request with a new or replaced Authorization header field (Section 4.2).
This refers to an
Authorization header, rather than a request body containing login credentials. The phrasing of the first part, unfortunately, could be misinterpreted to refer to a request body containing login information. This ambiguity can be resolved by considering separation of concerns; (https://en.wikipedia.org/wiki/Separation_of_concerns) the server's response header should not depend on the differences of two valid request bodies, with the exception of when it causes an internal server error, otherwise the concerns of data transfer and appliction login begin to creep into each other.
I would use HTTP response
2xx for a valid login request, where the client has permission to attempt a login, that is handled successfully with a response indicating success or failure.
Мне также нравится, как @spectras выразил это в комментариях:
Попытка выразить ошибку уровня приложения в коде состояния транспортного уровня является ошибкой проектирования.
Я думаю, что причина всей путаницы заключается в том, что есть два объекта, которые необходимо аутентифицировать. Во-первых, клиент (интерфейсное приложение) должен аутентифицировать себя, что он уполномочен делать запрос на вход для пользователя, а затем пользователь должен аутентифицировать себя с помощью своего имени пользователя/пароля.
Код состояния должен относиться только к клиенту, делающему запрос, а не к пользователю.
Из https://developer.mozilla.org/en-US/docs/Web/HTTP/Status
Коды состояния ответа HTTP указывают, был ли успешно выполнен конкретный HTTP-запрос.
200 является правильным: учитывая, что у вас есть внешнее приложение, которое взаимодействует с бэкэндом, соответствующий код ответа должен быть 200, а тело ответа должно содержать информацию о том, совпадает ли пароль или нет, но этот результат не влияет на код состояния , потому что сам запрос был авторизован и успешно проанализирован.
401 неправильно : предположим, что ваш интерфейс аутентифицируется, например, с помощью токена, а затем код ответа401будет означать, что токен внешнего интерфейса недействителен, а не пароль пользователя внутри этого запроса.
403 неправильно : предположим, что ваш интерфейс аутентифицируется, например, с помощью токена, а затем код ответа403будет означать, что токен действителен, но этот токен не имеет права доступа, чтобы спросить, совпадают ли пароль/имя пользователя.
401 - доступ запрещен
403 - запрещено
http://www.buggybread.com/2012/11/http-error-codes-401-access-denied-403.html
Если вы попытаетесь войти в учетную запись Google с неправильным паролем, он вернет ответ 200, содержащий данные, указывающие, что пароль был неправильным. По этой причине я просто использую 200.
В конце концов, какой код статуса вы используете, является чисто семантической проблемой и не повлияет на функциональность вашего приложения. Что действительно важно, так это то, что ваше приложение отображает правильную информацию для пользователя.
Я думаю, что будет хорошо установить код состояния ответа 200. Для предотвращения атаки на список слов. В огромных массах киберпреступники не могли определить, какой запрос и ответы верны)))