当资源可用但由于权限而无法访问时更正 HTTP 状态代码答案

【问题标题】：Correct HTTP status code when resource is available but not accessible because of permissions当资源可用但由于权限而无法访问时更正 HTTP 状态代码
【发布时间】：2011-04-02 15:02:05
【问题描述】：

我正在为我的计算机科学论文构建动态拼车应用程序的 RESTful 协议。

在协议中，我还必须正式指定每个操作的 HTTP 状态码。我有这个“隐私相关”的问题。假设如下：

GET /api/persons/angela/location

检索用户“angela”的当前位置。很明显，不是每个人都应该能够获得结果。只有安吉拉本人和可能会接她的司机应该能够知道。

我无法决定是返回 404 Not Found 还是 401 Forbidden here。

有什么提示吗？什么是最好的，为什么？

【问题讨论】：

这里的 404 是完全不正确的，因为它表示该记录根本不存在。

标签： http rest resources http-status-codes

【解决方案1】：

根据Wikipedia（和RFC 2616），当页面存在但需要认证时使用401码； 403 用于身份验证不会改变任何内容的页面。（在野外，403 通常意味着某些事情的权限是错误的，而 401 会提示用户输入用户名/密码）。 404 用于文档根本不存在的地方。

在您的情况下，401 似乎是最合适的代码，因为有一些方法可以验证有权访问该页面的用户。

【讨论】：

好一个！整个协议操作都需要身份验证。我遇到过资源可用但由于用户权限而无法检索的情况，以及由于先前已删除而资源不可用的情况。这两种情况都在经过身份验证的操作下。你会在第一种情况下选择 401，在第二种情况下选择 404 吗？因此：资源存在但不能访问-> 401 资源不存在-> 404
是的，如果一个资源被删除，如果随后尝试访问它，404 是合适的。
好答案，但我更喜欢“根据维基百科”说“根据 RFC 2616”tools.ietf.org/html/rfc2616#section-10.4.2 ;)
但是，给出 401 响应暴露了文件实际存在的事实。

【解决方案2】：

绝对不是 404。404 只是未找到。
401 被拒绝访问。
403被禁止。

我会选择 401

【讨论】：

401 不是拒绝访问。它是“未登录并需要登录”。
@EricStein 根据 RFC 2616 (tools.ietf.org/html/rfc2616#section-10.4.2)，“如果请求已包含授权凭据，则 401 响应表明这些凭据的授权已被拒绝。”所以 401 实际上是拒绝访问。

【解决方案3】：

如果请求中提供了授权凭据，并且请求者无权访问此资源，则应返回 403。

如果请求中未提供授权凭据，则应返回 401。

【讨论】：

如果请求中提供了授权凭据，并且请求者没有访问此资源的权限，那么您应该返回 401 而不是 403。RFC 2616 明确指出对于 403，“授权将无济于事并且不应重复请求”（tools.ietf.org/html/rfc2616#section-10.4.4）。因此，如果有有效的凭据可以授予访问资源的权限，请不要返回 403。
@Day 你是绝对正确的。我的回答是错误的。嗯，你每天都会学到新东西。
不用担心。试一试我的衍生问题stackoverflow.com/q/4038981/445073 :)
在我的场景中，无论请求者是否登录，某种数据库资源都是可用的。但是，就该网站而言，该资源可以设置为“私人”或“公共”。在这种情况下，授权凭证是无关紧要的； “It's set Private”的非标准状态是决定因素，所以我相信在这种情况下发回的适当状态是 HTTP 403 / Forbidden。

【解决方案4】：

对我来说，我将使用 400 Bad request。
因为我的应用程序不会以编程方式进入不可访问的资源。
在我看来，过滤用户权限并隐藏不可访问的资源是很好的用户体验。如果我的服务器收到无法访问的请求，这意味着有人试图做某事。
这就是为什么我在我的应用程序中选择 400 - Bad request。

【讨论】：

我不同意。以 400 Bad Request 响应有效请求是一个损坏的 API。 400 Bad Request 表示请求有问题。任何使用您的 API 的人都会认为请求是错误的，而实际上，请求是正确的，这实际上就是 401 和 403 的用途。它使调试变得更容易。
正如我所说，普通用户永远不会请求无法访问的资源。如果我的服务器收到无法访问的请求，这意味着一些鬼鬼祟祟的人试图破解无法访问的资源。此外，我永远不会响应有效请求的错误代码。
您通常不应该对普通用户会做什么和不会做什么做出假设。身份验证不一定是请求的一部分。如果您担心鬼鬼祟祟的人，正确的解决方案不是故意破坏 HTTP（默默无闻的安全性）。正确的解决方案是在你的 API 前面放一个防火墙，让鬼鬼祟祟的人一开始就无法探测你的 API。
我从来没有说过任何关于身份验证的事情。我的应用程序中有许多不同的部门和许多不同的用户角色。因为我的客户是非常大的公司。在我的应用程序中，这里有很多私人数据。因此，每个用户都是我的话题。谁知道他们的计算机是否被黑客入侵...在前端应用程序中永远不会以编程方式访问无法访问的资源。所以在服务器端，我将验证用户的每个请求，确保它是有效的请求。如果不是停止执行并响应 400。