Web.xml：爲什麼在安全約束中對url模式的靈活性很差？

Question

我正在使用GlassFish 3.1，並希望使用容器驗證。 當我開始在web.xml中編寫安全約束時，我感覺url模式幾乎沒有靈活性。 章12.2在Servlet 3.0規範描述了有效的URL模式的servlet映射：

1. 列表項
2. /事/ *爲路徑映射
3. *。擴展名的擴展名映射
4. 精確映射
5. 默認和上下文根例

12.1描述了匹配算法 和第2點狀態： 容器將遞歸嘗試匹配最長的路徑前綴。這是通過將路徑樹一次一個地刪除一個目錄，使用'/'作爲 路徑分隔符來完成的 。最長的匹配決定了所選的servlet。

安全約束在第13章和13.8.3中描述，似乎url-patterns和匹配算法與servlet的相同。

想象一下，您有一個遺留應用程序，其中包含以下列方式組織的JSF頁面： 每個實體類都有一個實體名稱包含4個JSF文件（List，edit，create，view）的目錄。 如果你想保護編輯和創建頁面的權限，該怎麼辦？在我看來，你只能在url-pattern中使用'精確匹配'，所以你必須爲你想要保護的每個頁面編寫一個約束，這個約束非常冗長而且乏味，容易出錯。 此外，如果我使用路徑映射規則保護整個目錄（例如/customers/*），我看不到任何方式可以解除該目錄中特定頁面的約束（例如，如果要釋放訪問到受保護目錄內的頁面'列表'）。

在與Glassfish的3.1我的實驗中注意到了這個怪異的行爲： 路徑映射工作得很好，只有當他們從上下文根絕，所以使用JSF默認配置就必須以「/面向」開始。如果我寫/customers/而不是/faces/customers/不評估安全約束。據我所知，這與12.1（上面報告）中所述的內容相反。

有人可以瞭解如何有效地使用url-pattern來定義安全約束嗎？ 顯然，您可以將所有敏感的JSF放入'/受保護的'目錄中，但這是一種非常侵入性的方式，可以實現破壞JSF任何邏輯順序的安全目標。

感謝 菲利波

Answer 1

有人可以闡明如何的url-pattern可以有效地用於定義安全約束一些輕？

經過幾年的Java EE，我覺得Java EE安全約束對於僅用於身份驗證是有用的。如果涉及授權（是授權執行特定操作的已知實體），則此安全模型會失敗，因爲它過於籠統（取決於URL）。你可以看看例如Spring Security。根據用例的複雜性，您可以考慮自己構建 - 特別是在涉及以數據爲中心的安全性時（例如，只有組織A中的用戶可以修改由組織B提供的數據）。

不是一個真正的答案，但我的意見...