0

我正在使用 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/*）保护整个目录，我看不到任何方法可以缓解该目录内特定页面的约束（例如，如果想要释放对 page 的访问权限） List' 在受保护的目录中）。

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

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

谢谢菲利波

4

1 回答 1

0

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

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

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

于 2011-08-22T18:47:38.997 回答