2

我目前正在构建一个 Web 应用程序（使用 Zend 框架）并且已经获取了一些基本的HTTP 状态代码，例如：

  • 缺少控制器/动作时出现 404
  • 服务器异常 500
  • Apache 返回 3xx

目前我刚刚实现了一些基本的ACL检查用户是否有权访问某个资源。它被实现为一个控制器插件，在 routeShutdown 事件上做它的事情。它的工作原理如下：

  1. 获取用户的角色。如果用户未登录，则分配“访客”角色

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

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

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

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

现在，我的问题：

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

5 回答 5

2

我认为 403 是正确的响应。根据HTTP 规范，401 用于 HTTP 级别身份验证可能且需要的情况，403 用于用户无权访问资源的情况。对于您的应用，用户已经登录，期望他/她能够使用不同的帐户是不合理的。

于 2009-08-14T12:17:25.930 回答
2

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

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

于 2009-08-14T12:43:45.407 回答
1

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

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

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

不过，只是我的看法。

于 2009-08-14T11:43:55.997 回答
1

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

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

于 2009-08-14T12:16:15.053 回答
1

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

401 - 认证错误 403 - 授权错误

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

于 2009-08-14T13:13:07.687 回答