在 Web 应用程序中使用 HTTP 状态代码
我目前正在构建一个 Web 应用程序（利用 Zend Framework），并且已经获得了一些基本的 HTTP 状态代码向下，例如：
- 404 缺少控制器/操作
- 500 服务器异常
- 3xx 由 Apache 返回
目前我刚刚实现了一些基本的 ACL 检查用户是否有权访问某个资源。 它作为控制器插件实现，在路由关闭事件。 它的工作原理如下：
- 获取用户的角色。 如果用户未登录，则分配“guest”角色
检查用户的规则是否有权访问资源
2.1。 如果他无法访问该资源并且是访客，请保存他尝试访问的资源，然后将他转到登录提示。 一旦他提供了凭据，他就会被重定向回原始资源（通过 HTTP 重定向状态代码）
2.2。 如果用户通过身份验证并且 ACL 拒绝他访问资源，他将被转发到错误控制器，执行我称为 noPrivilegies 的操作。
如果用户确实具有访问权限，则让请求照常继续。
现在，我的问题是：
- 我可以/应该在 2.1 场景中使用 HTTP 401 吗？ 这不像我想要客户端发送的 WWW-Authenticate 标头字段。 我只需要他通过我的登录表单登录。 但我仍然认为该请求不是 200 OK，因为他无法访问所请求的资源。
- 我可以/应该在 2.2 场景中使用 HTTP 401 吗？ 同样的原因，WWW-Authenticate 也无济于事。 也许使用 HTTP 403 Forbidden 更好？
- 您是否为这两种情况推荐任何其他状态代码？
- 您通常从应用程序中返回哪些其他状态代码，它们何时适用？
I'm currently building a web application (utilizing Zend Framework) and have gotten some of the basic HTTP status codes down, such as:
- 404 on missing controller/action
- 500 on server exception
- 3xx returned by Apache
At the moment I have just implemented some basic ACL checking that the user is authorized to access a certain resource. It's implemented as a controller plugin, doing its thing on the routeShutdown event. It works like follows:
- Get the role of the user. If the user is not logged in, assign the role of 'guest'
Check that the user's rule has access to the resource
2.1. If the does not have access to the resource and is a guest, save the resource he was trying to access, and forward him to a login prompt. Once he has supplied his credentials, he is redirected back to the original resource (via a HTTP redirect status code)
2.2. If the user is authenticated and the ACL denies him access to the resource, he is forwarded to the error controller, to an action I've called noPrivilegies.
If the user does have access, let the request continue as usual.
Now, my questions:
- Can/should I use HTTP 401 for the 2.1 scenario? It's not like I want a WWW-Authenticate header field sent by the client. I just need him to login through my login-form. But I still think that the request wasn't a 200 OK, since he didn't get access to the requested resource.
- Can/should I use HTTP 401 for the 2.2 scenario? Same reason here, WWW-Authenticate won't help. Perhaps it's better to use HTTP 403 Forbidden?
- Do you recommend any other status codes for these two scenarios?
- What other status codes do you usually return from your application, and when are they applicable?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
如果允许来宾角色执行某些操作，则在流程的第 2.1 阶段不会出现 4xx 响应或其他形式的错误，因为未登录不是错误。
401 和 403 都不是应用程序级“权限被拒绝”的理想选择，但权衡 401 的“响应必须包含 WWW-Authenticate 标头字段”和 403 的“授权不会有帮助”，我想说（而且大多数情况下）我迄今为止遇到的情况似乎都同意）如果您在继续之前请求 HTTP 级别身份验证，则 401 是适当的响应，而 403 在所有其他情况下都是适当的。 因此，在您的情况下可能是 403。
Provided that the guest role may be allowed to perform some actions, then no 4xx response or other form of error is warranted at stage 2.1 of your process because not being logged in is not an error.
Neither 401 nor 403 is really ideal for an application-level "permission denied", but weighing 401's "The response MUST include a WWW-Authenticate header field" against 403's "Authorization will not help", I would say (and most cases I've encountered to date seem to agree) that 401 is the appropriate response if you are requesting HTTP level authentication before proceeding and 403 is appropriate in all other cases. So probably 403 in your case.
我认为 403 是正确的响应。 根据 HTTP 规范，401 适用于可能且需要 HTTP 级别身份验证的情况, 403 用于用户没有权限访问资源的情况。 对于您的应用程序，用户已经登录，并且期望她/他能够使用不同的帐户是不合理的。
I think that 403 is the correct response. Per the HTTP spec, 401 is for cases where HTTP-level authentication is possible and required, 403 is for cases where the user does not have permission to access the resource. In the case of your app, the user has logged in, and it's unreasonable to expect that s/he will be able to use a different account.
通常我不会使用状态代码来报告“应用程序”级身份验证失败。 这通常是通过应用程序报告的。
这样做是有道理的； 因为他们可以从“http”意义上访问“页面”； 他们只是无法访问您的应用程序对该页面的处理（如果这有意义的话）。
我的意思是，在将数据返回给客户端时，通常您不必担心代码，或者根本不需要自己设置它们。 将其留给网络服务器并提供“抽象”的响应方法； 即典型的“无效的用户名或密码”页面等。
不过，这只是我的观点。
Normally I don't ever use the status codes to report 'application' level authentication failures. That's generally reported via the app.
And it makes sense to do that; because they can access the 'page' from a 'http' sense; they just can't access your applications processing of that page, if that makes sense.
What I'm saying is generally you don't worry about the codes, or set them yourself at all, when returning data to the client. Leave it to the webserver and provide an 'abstracted' method of responding; i.e. the typical 'invalid username or password' page, etc.
Just my view, though.
我最近实现了一些以类似方式工作的东西，当用户必须登录时我们返回 401 响应，如果登录后他们尝试访问他们无权访问的内容，我们会返回 403 响应。
您还可以将 http 响应中的原因短语设置为表示失败原因的内容。
i've recently implemented something that works in a similar way, we return a 401 response when a user has to login and a 403 if after login they've tried accessing something that they don't have permission to access.
you can also set the reason phrase in the http response to something to denote the reason for the failure.
即使 HTTP 规范中没有具体说明，常见的做法也是
401 - 身份验证错误
403 - 授权错误
如果您不想验证用户身份，请尽量不要使用 401。 我最近遇到了一个 HTTP 客户端（不是流行的浏览器之一）的问题，当它看到 401 而不是 WWW-Authenticate 标头时，它会记录错误。 虽然这是客户端的一个错误，但它显示了人们如何看待 401。
Even not specifically stated in HTTP spec, the common practice is
401 - For authentication error
403 - For authorization error
Try not to use 401 if you don't want authenticate user. I recently encountered a problem with a HTTP client (not one of the popular browsers) that it logs an error when it sees 401 but not WWW-Authenticate header. Granted this is a bug on the client side but it shows how people perceives 401.