对于存在但用户没有足够权限(他们未登录或不属于正确的用户组)的网页,要提供的正确HTTP响应是什么?

401未授权?403禁止?还有别的吗?

到目前为止,我读到的每一篇文章都不太清楚两者之间的区别。每个响应都适合哪些用例?


当前回答

401:您需要HTTP基本身份验证才能看到这一点。

如果用户只需要使用您站点的标准HTML登录表单登录,401将不合适,因为它特定于HTTP基本身份验证。

403:此资源存在,但您无权查看它,HTTP基本身份验证也无济于事。

我不建议使用403来拒绝访问/包含之类的内容,因为就web而言,这些资源根本不存在,因此应该使用404。

换句话说,403表示“此资源需要HTTP基本身份验证以外的某种身份验证(例如使用网站的标准HTML登录表单)”。

https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2

其他回答

根据RFC 2616(HTTP/1.1)403在以下情况下发送:

服务器理解该请求,但拒绝履行该请求。授权没有帮助,不应重复该请求。如果请求方法不是HEAD,并且服务器希望公开请求未完成的原因,则应在实体中描述拒绝的原因。如果服务器不希望向客户端提供此信息,则可以使用状态代码404(未找到)

换句话说,如果客户端可以通过认证访问资源,则应发送401。

我对它的看法与公认的答案略有不同。

当认证失败时返回403,当授权失败时返回401,这似乎更符合语义和逻辑。

我的理由如下:

当您请求认证时,您有权提出该请求。你需要这样做,否则一开始就没有人能够通过认证。

如果您的身份验证失败,您将被禁止,这是有意义的。

另一方面,被禁止者也可以申请授权,但假设您已通过身份验证,但无权访问特定端点。返回401 Unauthorized似乎更有意义。

对于失败的身份验证尝试,Spring Boot的安全性返回403

其含义如下:

401:用户未(正确)验证,资源/页面需要验证

403:用户的角色或权限不允许访问请求的资源,例如,用户不是管理员,请求的页面是管理员的。

注意:从技术上讲,403是401的超集,因为给未经认证的用户403也是合法的。无论如何,区分更有意义。

其他答案缺少的是,必须理解RFC 2616上下文中的认证和授权仅指RFC 2617的HTTP认证协议。HTTP状态代码不支持RFC2617以外的方案进行认证,并且在决定是否使用401或403时不考虑。

Brief和Terse

未授权表示客户端未通过RFC2617认证,服务器正在启动认证过程。Forbidden表示客户端已通过RFC2617认证且没有授权,或者服务器不支持请求资源的RFC2617。

也就是说,如果您拥有自己的登录过程,并且从不使用HTTP身份验证,那么403始终是正确的响应,而401永远不应该使用。

详细和深入

来自RFC2616

10.4.2 401未授权请求需要用户身份验证。响应必须包括WWW Authenticate报头字段(第14.47节),该字段包含适用于所请求资源的质询。客户端可以使用适当的授权头字段重复请求(第14.8节)。

and

10.4.4 403禁止服务器理解该请求,但拒绝履行。授权不会有帮助,不应重复该请求。

首先要记住的是,本文档中的“身份验证”和“授权”特指RFC 2617中的HTTP身份验证协议。它们不引用您可能使用登录页面等创建的任何滚动您自己的身份验证协议。我将使用“登录”来引用除RFC2617以外的方法进行的身份验证和授权

因此,真正的区别不在于问题是什么,甚至不在于是否有解决方案。区别在于服务器希望客户端接下来做什么。

401指示无法提供资源,但服务器正在请求客户端通过HTTP身份验证登录,并已发送回复标头以启动进程。可能存在允许访问资源的授权,也可能没有,但让我们尝试一下,看看会发生什么。

403指示不能提供资源,并且对于当前用户来说,没有办法通过RFC2617来解决这一问题,也没有尝试的意义。这可能是因为已知没有足够的认证级别(例如,由于IP黑名单),但也可能是因为用户已经认证且没有权限。RFC2617模型是一个用户,一个证书,因此可以忽略用户可能具有可被授权的第二组证书的情况。它既不暗示也不暗示某种登录页面或其他非RFC2617认证协议可能有帮助,也可能没有帮助,这超出了RFC2616标准和定义。


编辑:RFC2616已过时,请参阅RFC7231和RFC7235。

假设正在使用HTTP身份验证(WWW-Authenticate和Authorization标头),如果以其他用户身份进行身份验证将授予对所请求资源的访问权限,则应返回401 Unauthorized。

403 Forbidden用于禁止所有人访问资源或限制访问给定网络或仅允许通过SSL访问资源,只要与HTTP身份验证无关。

如果HTTP身份验证未被使用,并且服务具有基于cookie的身份验证方案,这是现在的标准,那么应该返回403或404。

关于401,这来自RFC 7235(超文本传输协议(HTTP/1.1):认证):

3.1.401未经授权401(未授权)状态代码表示请求尚未应用,因为它缺少目标资源的有效身份验证凭据。源服务器必须发送一个WWW Authenticate头字段(第4.4节),其中至少包含一个适用于目标资源的质询。如果请求包括认证证书,则401响应指示已拒绝对这些证书的授权。客户端可以使用新的或替换的授权头字段重复请求(第4.1节)。如果401响应包含与先前响应相同的挑战,并且用户代理已经至少尝试了一次身份验证,则用户代理应该向用户呈现随附的表示,因为它通常包含相关的诊断信息。

403(和404)的语义随着时间而改变。这来自1999年(RFC 2616):

10.4.4 403禁止服务器理解该请求,但拒绝履行该请求。授权没有帮助,不应重复该请求。如果请求方法不是HEAD,并且服务器希望公开请求未完成的原因,则应在实体中描述拒绝的原因。如果服务器不希望向客户端提供该信息,则可以使用状态代码404(未找到)。

2014年,RFC 7231(超文本传输协议(HTTP/1.1):语义和内容)改变了403的含义:

6.5.3.403禁止403(禁止)状态代码表示服务器理解请求但拒绝授权。希望公开请求被禁止的原因的服务器可以在响应有效负载(如果有的话)中描述该原因。如果请求中提供了身份验证凭据,则服务器认为这些凭据不足以授予访问权限。客户端不应使用相同的凭据自动重复请求。客户端可以使用新的或不同的凭据重复请求。但是,由于与凭据无关的原因,请求可能被禁止。希望“隐藏”当前存在的禁用目标资源的源服务器可能会以状态代码404(未找到)进行响应。

因此,403(或404)现在可能意味着任何事情。提供新凭据可能会有所帮助。。。或者可能不会。

我相信这一变化的原因是RFC 2616假设在实践中,当今天的Web应用程序使用例如表单和cookie构建自定义身份验证方案时,将使用HTTP身份验证。