如果用户尝试使用不正确的用户名/密码登录,但格式正确,则返回的HTTP状态代码是什么？

Question

此处发布了一个类似的问题:REST API服务为验证失败返回的适当HTTP状态代码是什么？

上面的线程中的答案指出"例如,如果URI应该具有ISO-8601日期,并且您发现它的格式错误或者指的是2月31日,那么您将返回HTTP 400.如果您期望它同样如此实体主体中格式良好的XML,无法解析."

但是,如果用户提交了正确格式的数据,会发生什么？我的意思是,用户提交了用户名和密码的简单字母字符串/文本(这对我的应用程序完全有效).唯一的问题是密码与用户名不匹配.在这种情况下,400将是不正确的,因为它是完全有效的语法和格式良好.

一个401是不正确的(这里建议:哪个HTTP状态代码说用户名或密码不正确？)因为用户没有尝试访问任何页面,他只是尝试登录并输入不匹配的数据.

如果你回顾我链接的第一篇文章,第二个答案表明422是正确的响应(看起来对我来说是正确的),但是,我使用的是Django Rest Framework而422并不是状态代码的一部分(a可以在此处找到属于DRF的状态代码列表:http://www.django-rest-framework.org/api-guide/status-codes/#client-error-4xx)

404也看起来不正确,因为数据被成功接受而不被拒绝.

话虽如此,应该使用的真正正确答案是什么？

Answer 1

正确的HTTP代码实际上是401.来自RFC:

401(未授权)状态代码表示尚未应用请求,因为它缺少目标资源的有效身份验证凭据.生成401响应的服务器必须发送WWW-Authenticate头字段(第4.1节),其中包含至少一个适用于目标资源的质询.

如果请求包含身份验证凭据,则401响应表示已拒绝授权这些凭据. 用户代理可以使用新的或替换的Authorization头字段重复请求(第4.2节).

Answer 2

正确的 HTTP 响应状态代码是 200。

我认为造成所有混乱的原因是有两个实体需要进行身份验证。首先，客户端（前端应用程序）必须验证其授权才能代表用户发起登录请求。其次，用户必须通过提供用户名和密码来验证自己的身份。

关于 HTTP 响应状态代码，需要注意的是，它们仅与发出请求的客户端相关，与用户无关。无论用户凭据的身份验证状态如何，成功请求的相应响应代码为 200。响应正文应包含有关密码是否匹配的信息，但这对状态代码没有影响，因为请求已成功授权并解析。

响应代码 401 表示前端令牌无效，而不是用户的密码。同样，响应代码 403 表示令牌有效，但它没有请求用户凭据的身份验证信息所需的访问权限。

另请参阅https://developer.mozilla.org/en-US/docs/Web/HTTP/Status

200 好

请求成功。POST：描述操作结果的资源在消息正文中传输。

这是这里描述的情况，用户名/密码已成功传输。操作的结果位于响应的消息正文中。

401 未经授权

尽管 HTTP 标准指定了“未经授权”，但从语义上讲，此响应意味着“未经身份验证”。也就是说，客户端必须验证自己的身份才能获得请求的响应。

意味着客户端未经身份验证来询问用户名/密码是否匹配（令牌已过期或类似）

403 禁忌

客户没有内容的访问权限；也就是说，它是未经授权的，因此服务器拒绝提供所请求的资源。与 401 Unauthorized 不同，服务器知道客户端的身份。

意味着客户端已通过身份验证，但无权询问用户名/密码是否匹配（令牌未过期，但客户端无权执行此操作）

Answer 3

401 - 未经授权

403 - 禁止

http://www.buggybread.com/2012/11/http-error-codes-401-access-denied-403.html

Answer 4

使用适当的状态代码2xx成功处理密码错误的登录请求。

在问“什么是正确的 HTTP 状态码”之前，重要的是考虑这个问题：“登录的成功或失败应该反映在响应的 HTTP 状态码中吗？”

在@sjagr 的回答中，突出显示了本节的第一部分。我将重点介绍第二部分并解释原因：

如果请求包含身份验证凭据，则 401 响应表明对这些凭据的授权已被拒绝。用户代理可以使用新的或替换的授权头字段（第 4.2 节）重复请求。

这指的是Authorization标头，而不是包含登录凭据的请求正文。不幸的是，第一部分的措辞可能会被误解为引用包含登录信息的请求正文。这种歧义可以通过考虑关注点分离来解决；( https://en.wikipedia.org/wiki/Separation_of_concerns ) 服务器的响应头不应该依赖于两个有效请求体的差异，除非它导致服务器内部错误，否则数据传输和应用程序登录开始相互渗透。

我将对2xx有效的登录请求使用 HTTP 响应，其中客户端有权尝试登录，成功处理并显示成功或失败的响应。

我也喜欢@spectras 在评论中表达的方式：

试图在传输级状态代码中表达应用程序级错误是一个设计错误。