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

发布于 2024-09-15 05:43:39 字数 307 浏览 4 评论 0原文

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

在协议中,我还必须正式指定每个操作的 HTTP 状态代码。我遇到了这个“隐私相关”问题。假设如下:

GET /api/persons/angela/location

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

我无法决定是否在此处返回 404 Not Found 还是 401 Forbidden。

有什么提示吗?什么是最好的,为什么?

I am building a RESTful protocol for Dynamic Carpooling applications, for my Computer Science thesis.

In the Protocol I also have to formally specify the HTTP status code for each operation. I've got this "privacy related" problem. Suppose the following:

GET /api/persons/angela/location

Retrieves the current position of user "angela".
It is obvious that not everybody should be able to obtain a result. Only angela itself and a possible driver that is going to pick her should be able to know it.

I can not decide whether to return a 404 Not Found or a 401 Forbidden here.

Any hints? What would be the best one and why?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

望笑 2024-09-22 05:43:39

根据维基百科(和RFC 2616),当页面存在但需要身份验证时使用 401 代码; 403 表示身份验证不会改变任何内容的页面。 (在野外,403 通常意味着某些权限错误,而 401 会提示用户输入用户名/密码)。 404 表示文档根本不存在。

就您而言,401 似乎是最合适的代码,因为有某种方法可以对有权访问该页面的用户进行身份验证。

According to Wikipedia (and RFC 2616), a 401 code is used when a page exists but requires authentication; 403 is for a page where authenticating won't change anything. (In the wild, 403 usually means the permissions on something are wrong, whereas a 401 will prompt the user for a username/password). 404 is for where the document simply doesn't exist.

In your case, it seems like 401 is the most appropriate code, since there is some way of authenticating the users who DO have access to the page.

Hello爱情风 2024-09-22 05:43:39

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

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

If authorization credentials are provided in the request and the requester does not have permissions to access this resource then you should return 403.

If no authorization credentials are provided in the request then you should return 401.

三生一梦 2024-09-22 05:43:39

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

我会选择401

Definitely NOT 404. 404 is just Not Found.
401 is access denied.
403 is forbidden.

I would go with 401

一个人练习一个人 2024-09-22 05:43:39

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

To me I will use 400 Bad request.
Because my application will not go unaccessable resources in programmatically.
Filtering users permission and hide unaccessable resources is good user experience in my opinion.
If my server got unaccessable request which means some person trying to do something.
That is why I choose 400 - Bad request in my applications.

南城旧梦 2024-09-22 05:43:39

如果用户具有有效的凭据,但没有查看资源的权限,则会出现错误 403。如果用户未经过身份验证(且需要进行身份验证),则会出现错误 401。根据 rfc https://www.rfc-editor.org/rfc/rfc2616#section-10.4.2,错误401表示缺少凭据,错误 403 表示其他授权问题,例如尽管已登录但未授予权限。但只有在您解释拒绝原因(例如缺乏权限)时才应使用它,如果没有解释拒绝的情况根据 RFC,如果提供了经过身份验证的用户,您可以使用 404 错误。

If the user has valid credentials, but does not have permission to view the resource, error 403. If he is not authenticated, and needs to be, error 401. According to rfc https://www.rfc-editor.org/rfc/rfc2616#section-10.4.2, error 401 indicates missing credentials, and error 403 indicates other authorization issues, such as not being granted permission despite being logged in. But it should only be used if you explain the reason for the refusal (lack of permission for example), if no explanation for the refusal of an authenticated user is provided, you can use the 404 error, according to the RFC.

木落 2024-09-22 05:43:39

截至本文发布之日,即 2023 年 11 月 13 日,当前 RFC 可能会建议 403 表示权限不足。

https://datatracker.ietf.org/doc/html/rfc9110# name-403-禁止

At the date of this post, 13 Nov 2023, the current RFC may recommend 403 for insufficient permissions.

https://datatracker.ietf.org/doc/html/rfc9110#name-403-forbidden

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文