Java HTTP 404应该先于HTTP 403状态代码吗？

我用SpringMVC3.1创建了一个web服务（RESTful），并添加了Spring安全性。其中一个端点是

/users/{id}

，它应该只对管理员可用。但是，当且仅当检索到的资源的用户名与登录用户的用户名匹配时，

/users/{id}

也可供用户使用。这可以通过使用@PostAuthorize注释来解决

现在，如果用户访问

/users/999

（不是登录用户），我应该返回HTTP状态404还是HTTP状态403？目前我正在做一个404（未找到），但它应该是一个403，因为用户不应该能够访问它

如果是这样，当您依赖@PostAutorize注释时，您将如何做到这一点

@PostAuthorize("returnObject.username == principal.username and hasRole('ROLE_USER')")

---

您应该使用403，因为资源可用，但不允许使用用户。HTTP 403规范明确提到：

服务器理解该请求，但拒绝满足该请求。 授权没有帮助，请求不应重复。如果 请求方法不是HEAD，服务器希望公开 为什么请求未得到满足，应说明原因 对于实体中的拒绝。如果服务器不希望 此信息可供客户端使用，状态代码为404（不适用） 找到）可以改为使用

web服务器可以返回403禁止的HTTP状态码作为响应 客户端对网页或资源的请求，以指示 服务器拒绝允许请求的操作。换句话说 无法访问服务器，但服务器拒绝允许请求的访问 进入

---

您应该使用403，因为资源可用，但不允许使用用户。HTTP 403规范明确提到：

服务器理解该请求，但拒绝满足该请求。 授权没有帮助，请求不应重复。如果 请求方法不是HEAD，服务器希望公开 为什么请求未得到满足，应说明原因 对于实体中的拒绝。如果服务器不希望 此信息可供客户端使用，状态代码为404（不适用） 找到）可以改为使用

web服务器可以返回403禁止的HTTP状态码作为响应 客户端对网页或资源的请求，以指示 服务器拒绝允许请求的操作。换句话说 无法访问服务器，但服务器拒绝允许请求的访问 进入

---

我会使用404，因为资源是否存在不是非管理用户应该拥有的信息。这甚至包括在：

服务器理解该请求，但拒绝满足该请求。 授权没有帮助，请求不应重复。 如果请求方法不是HEAD并且服务器希望 公开为什么请求没有得到满足，它应该描述 实体中拒绝的原因如果服务器不希望 将此信息提供给客户端，状态代码404 （未找到）可以改为使用。

（我的重点。）

如果改为使用403，则在答复不存在的资源的非管理员请求时必须使用403，否则您的实现将向不应该拥有该信息的非管理员用户泄漏信息（哪些用户存在，哪些用户不存在）

---

使用403（即使用户不存在）是有道理的，但我认为404可以解决这个问题。但是，无论您使用哪一种，在回复非管理员用户对用户页面的请求（而非他们自己的页面）时，都要一致使用它，以避免信息泄漏。

我会使用404，因为资源是否存在不是非管理员用户应该拥有的信息。这甚至包括在：

服务器理解该请求，但拒绝满足该请求。 授权没有帮助，请求不应重复。 如果请求方法不是HEAD并且服务器希望 公开为什么请求没有得到满足，它应该描述 实体中拒绝的原因如果服务器不希望 将此信息提供给客户端，状态代码404 （未找到）可以改为使用。

（我的重点。）

如果改为使用403，则在答复不存在的资源的非管理员请求时必须使用403，否则您的实现将向不应该拥有该信息的非管理员用户泄漏信息（哪些用户存在，哪些用户不存在）

---

使用403（即使用户不存在）是有道理的，但我认为404可以解决这个问题。但是，无论您使用哪种配置，在回复非管理员用户对用户页面的请求时都要一致地使用它，以避免信息泄漏。

那么，使用我提到的配置，您将如何使用Spring Security？顺便说一句：在这种情况下，999不是资源，甚至不是管理员的资源。它不存在。如果资源存在，则返回403。但事实上它并不存在。@LuckyLuke:小心信息泄露！如果用户看不到

/users/999

（它不存在）和

/users/998

（它存在），您不想用404回复

/users/999

，而想用403回复

/users/998

。这泄露了用户几乎肯定不应该访问的信息。要么始终使用404，要么始终使用403（当管理员请求一个不存在的用户时，您可以使用404，因为这是允许他们知道的信息）。@t.J.Crowder如果您的应用程序是安全的，则信息泄漏无关紧要。如果只返回404，则调试授权问题将有所不同。因为您无法确定404是否是因为资源不可用或用户不允许访问i