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提供的数据）。

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