在Web应用程序中使用HTTP状态代码

Question

我目前正在构建一个Web应用程序（使用Zend Framework），并且已经删除了一些基本的HTTP status代码，例如：

• 404失踪控制器/行动
• 500 on server exception
• 3xx由Apache返回

目前我刚刚实施了一些基本ACL检查，用户有权访问某个资源。它被实现为controller plugin，在routeShutdown事件中执行它的操作。它的工作原理如下：

1. 获取用户的角色。如果用户未登录，请指定“guest”
的角色

2. 检查用户的规则是否有权访问资源

   2.1。如果不可以访问资源并且是访客，请保存他尝试访问的资源，并将其转发到登录提示。一旦他提供了他的凭证，他就被重定向回原始资源（通过HTTP重定向状态代码）

   2.2。如果用户通过身份验证并且ACL拒绝他访问资源，则会将其转发给错误控制器，转到我称之为noPrivilegies的操作。

3. 如果用户确实有权访问，请让请求继续照常进行。

现在，我的问题：

1. 可以/应该在2.1场景中使用HTTP 401吗？这不像我想要客户端发送的WWW-Authenticate头字段。我只需要他登录我的登录表单。但我仍然认为请求不是200 OK，因为他无法访问所请求的资源。
2. 可以/应该在2.2场景中使用HTTP 401吗？同样的原因，WWW-Authenticate无济于事。也许最好使用HTTP 403 Forbidden？
3. 您是否为这两种情况推荐了其他任何状态代码？
4. 您通常会从应用程序返回哪些其他状态代码，以及它们何时适用？

Answer 1

我认为403是正确的回答。根据{{​​3}}，401适用于可能且需要HTTP级别身份验证的情况，403适用于用户无权访问资源的情况。对于您的应用，用户已登录，并且期望他/她能够使用其他帐户是不合理的。

Answer 2

1. 如果允许guest角色执行某些操作，则在您的流程的阶段2.1中不保证4xx响应或其他形式的错误，因为未登录不是错误。

2. 401和403都不是理想的应用程序级别“权限被拒绝”，但是权重401的“响应必须包含WWW-Authenticate头字段”对403的“授权无济于事”，我会说（并且我迄今为止遇到的大多数情况似乎都同意）如果您在继续之前请求HTTP级别身份验证并且403适用于所有其他情况，则401是适当的响应。你的情况可能就是403。

Answer 3

通常，我不会使用状态代码来报告“应用程序”级别身份验证失败。这通常是通过应用程序报告的。

这样做是有道理的;因为他们可以从'http'意义上访问'page';他们只是无法访问您的应用程序处理该页面，如果这是有道理的。

我所说的通常是在将数据返回给客户端时，您不必担心代码或自己设置代码。将其留给网络服务器并提供“抽象”的响应方法;即典型的“无效用户名或密码”页面等

只是我的看法。

Answer 4

我最近实现了以类似方式工作的东西，当用户必须登录时返回401响应，如果登录后他们尝试访问他们无权访问的东西，则返回403。 / p>

您还可以在http响应中设置原因短语，以表示失败的原因。

Answer 5

即使没有在HTTP规范中明确说明，通常的做法是

401 - 出于身份验证错误   403 - 授权错误

如果您不想要身份验证用户，请尽量不要使用401。我最近遇到了一个HTTP客户端（不是一个流行的浏览器）的问题，它在看到401而不是WWW-Authenticate标头时记录错误。虽然这是客户端的一个错误，但它显示了人们如何看待401。