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

Question

我目前正在构建一个 Web 应用程序(利用 Zend Framework)并获得了一些基本的 HTTP status代码下来，例如:

• 404 缺少 Controller /操作
• 500 服务器异常
• Apache 返回的 3xx

目前我刚刚实现了一些基本的 ACL检查用户是否有权访问特定资源。它被实现为 controller plugin ，在 routeShutdown 事件上做它的事情。它的工作原理如下:

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

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

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

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

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

现在，我的问题:

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

Answer 1

1. 如果可以允许 guest 角色执行某些操作，那么在流程的第 2.1 阶段就不会保证出现 4xx 响应或其他形式的错误，因为未登录不是错误。

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