Web.xml：为什么安全约束中 url 模式的灵活性如此之差？

Question

我正在使用 GlassFish 3.1 并希望使用容器身份验证。 当我开始在 web.xml 中编写安全约束时，我感觉 url 模式的灵活性很小。 Servlet 规范 3.0 中的第 12.2 章描述了 servlet 映射的有效 url 模式：

1. 列表项
2. /something/* 用于路径映射
3. *.extension 用于扩展映射
4. 精确映射
5. 默认和上下文根案例

12.1 描述匹配算法 并在第 2 点指出： 容器将递归地尝试匹配最长的路径前缀。这个做完了 通过将路径树一次下移一个目录，使用“/”字符作为 路径分隔符。最长的匹配决定了选择的 servlet。

安全约束在第 13 章中有所描述，从 13.8.3 开始，似乎 url-patterns 和匹配算法与 servlet 相同。

假设您有一个遗留应用程序，其中 JSF 页面按以下方式组织： 对于每个实体类，都有一个实体名称目录，其中包含 4 个 JSF 文件（列表、编辑、创建、查看）。 如果您想保护编辑和创建页面的访问权怎么办？在我看来，您只能在 url 模式中使用“完全匹配”，因此您必须为要保护的每个页面编写一个约束，这是非常冗长乏味且容易出错的活动。 此外，如果我使用路径映射规则（例如 /customers/* ）保护整个目录，我看不到任何方法可以缓解该目录内特定页面的约束（例如，如果想要释放对受保护目录内“列表”页面的访问）。

在 Glassfish 3.1 的实验中，我注意到了这种奇怪的行为： 路径映射只有在上下文根中是绝对的时才能正常工作，因此使用 jsf 默认配置，它们必须以“/faces”开头。如果我写 /customers/ 而不是 /faces/customers/ 则不会评估安全约束。根据我的说法，这与 12.1 中所述的内容（如上文所述）形成对比。

有人可以阐明如何有效地使用 url-pattern 来定义安全约束吗？ 显然，您可以将所有敏感的 JSF 放在一个 '/protected' 目录中，但这是一种非常侵入性的方式来实现安全目标，它会破坏 JSF 的任何逻辑顺序。

谢谢 菲利波

Answer 1

有人可以阐明如何有效地使用 url-pattern 来定义安全约束吗？

我不能，经过几年的 Java EE，我觉得 Java EE 安全约束仅对身份验证有用。如果涉及授权（是被授权执行特定操作的已知实体），则此安全模型会失败，因为它过于笼统（取决于 URL）。你可以看看例如春季安全。根据用例的复杂性，您可以考虑自行构建 - 特别是在涉及以数据为中心的安全性时（例如，仅允许组织 A 中的用户修改组织 B 提供的数据）。

不是真正的答案，但我的意见......