HTTP 404是否應該在HTTP 403狀態碼之前？

我已經使用Spring MVC 3.1創建了一個Web服務（RESTful），並添加了Spring安全性。其中一個端點是/users/{id}，只應供管理員使用。但是，當且僅當檢索到的資源的用戶名與登錄用戶的用戶名相匹配時，/users/{id}也可用於用戶。這可以通過使用@PostAuthorize註解來解決。HTTP 404是否應該在HTTP 403狀態碼之前？

現在，如果用戶訪問/users/999（它不是登錄用戶），我應該返回HTTP狀態404還是HTTP狀態403？目前我正在做一個404（未找到），但應該是403，因爲用戶應該無法訪問它？

如果是這樣，那麼當你依賴@PostAutorize註解時，你會怎麼做？

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

來源

2013-05-12 LuckyLuke

我會用404，因爲資源是否存在不是非管理用戶應該擁有的信息。這甚至涵蓋在the HTTP specification with regard to code 403：

服務器瞭解請求，但拒絕履行它。授權不起作用，請求不應重複。如果請求方法不是HEAD並且服務器希望公開請求未被滿足的原因，它應該描述實體中拒絕的原因。 如果服務器不希望將此信息提供給客戶端，則可以使用狀態碼404 （未找到）代替。

（我的重點。）

如果使用403代替，你必須回答的一個不存在的資源非管理員請求時使用403，否則你會實現將信息（用戶存在與否）泄露給不應該擁有該信息的非管理員用戶。

有一個使用403（即使用戶不存在）的參數，但我認爲404將其劃掉。但是，無論您使用何種方式，在回覆來自非管理用戶的非用戶頁面請求時，請始終使用，以避免信息泄露。

來源

2013-05-12 14:03:47

所以這意味着我現在正在做正確的事情。 – LuckyLuke 2013-05-12 17:22:00

@LuckyLuke：爲了我的頭腦，是的。 – 2013-05-12 17:57:25

作爲一個筆記本，我會將其標記爲信息披露，因爲我可以枚舉賬戶。一般來說，作爲一名開發人員，我永遠不會爲任何事情（包括資源路徑）返回403的HTTP狀態代碼。 – Casey 2016-02-19 20:15:44

您應該使用403作爲資源可用但用戶不被允許。 HTTP 403規範明確提到：

服務器理解請求，但拒絕履行它。授權不起作用，請求不應重複。如果請求方法不是HEAD，並且服務器希望公開爲什麼請求沒有被滿足，它應該描述在實體中拒絕的原因。如果服務器不希望向客戶端提供此信息，則可以使用狀態代碼404（不是找到）代替。

web服務器可以響應從客戶端返回一個403禁止HTTP狀態代碼的請求一個網頁或資源，以表明服務器拒絕允許請求的操作。換句話說，可以到達服務器，但服務器拒絕允許請求的訪問。

來源

2013-05-12 13:57:05

那麼，你如何用Spring Security與我提到的配置一起做？ – LuckyLuke 2013-05-12 13:57:39

順便說一句：在這種情況下，999不是一個資源，即使是管理員。它不存在。如果資源存在，則返回403.但是，情況並不存在。 – LuckyLuke 2013-05-12 13:58:12

如果實體不存在，那麼404是正確的選擇。 – 2013-05-12 14:00:01

HTTP 404是否應該在HTTP 403狀態碼之前？

回答

相關問題