春季安全，方法安全，URL安全

我學習春天的安全，但我感到困惑與它的靈活性..春季安全，方法安全，URL安全

我知道我可以在標籤定義規則保護的URL然後我看到有一個@secure註解可以保護方法。然後還有其他註釋來保護讀/更新域（或POJO）

因此，當我想開發一個典型的權限/角色/用戶的Web應用程序，除了創建規則來保護網址，我也必須使用@secure註釋來保護方法？

ej。

用戶輸入限制網址
應用要求登錄
應用程序檢查，如果該角色可以訪問的URL
用戶再次選擇
檢查「新增」選項，如果用戶有權限調用方法「addNew（）」？

或者步驟4或5中的一個是多餘的。

對不起我的英語

來源

2012-05-31 Kossel

這是最重要的事情要記住。您需要必須假設用戶可以通過原始HTTP GET或POST將任何東西發送到您的Web應用程序。這也被稱爲「永不相信客戶」。所以上面的步驟4和5不是多餘的。例如，如果您到達第5步，則無法確定第3步發生了。這就是說，如果你可以通過單獨的URL 和準確地區分用戶打算做什麼，你不需要通過不同的訪問通道（比如隊列或RMI）來保護該方法，那麼你可以逃脫只保護URL。但是，無論如何，具有方法級安全性仍然不失爲一個好主意......出於以下幾個原因。首先，它在正在執行邏輯的位置記錄預期角色。這有助於理解在開發時做出的假設，這有助於未來的增強。其次，它可以確保通過未來訪問渠道的安全性不會被無意中損害。

來源

2012-05-31 03:49:36

謝謝你的回答。所以如果我保證每一個方法/類，我仍然需要保護URL？或者僅僅爲匿名/用戶/管理模式組合一個簡單規則 – Kossel

如果您的URL大致按角色分組，則URL可能更易於保護（例如，需要ROLE_ADMIN的'admin/**'URL）。但是，您經常無法以這種方式構建應用程序，角色比這更復雜，或者URL本身根本不提供太多信息（即大部分信息都在請求正文中）。但是，在URL層次上有一些不錯的主意，尤其是對於基於非Java的文件（如果您有任何文件並在Web應用程序中爲其提供服務）。 –

例如，通過查看流暢的API of HttpSecurity可以看出，URL級安全性非常豐富。但至少有兩個原因在春季安全使用方法級別的安全性：

正如喬納森·w ^指出，您的安全邏輯可以通過HTTP以外的連接器類型的訪問。例如，邏輯可能通過EJB公開。
對於REST API，相同的URI可能支持具有不同授權規則的不同http方法。例如，/myapi/order/{id}可能接受GET和DELETE，並且DELETE可能僅適用於具有管理員角色的用戶。您不能通過URL安全來指定該規則，但您可以通過方法安全性來執行此操作，例如在處理DELETE的方法上使用@Secured("Supervisor")。

來源

2016-09-01 20:38:36

春季安全，方法安全，URL安全

回答

相關問題