我正在使用GlassFish 3.1并希望使用容器身份验证。 当我开始在web.xml中编写安全性约束时，我感觉网址模式的灵活性很小。 Servlet规范3.0中的第12.2章描述了servlet映射的有效url模式：
12.1描述了匹配算法 在第2点陈述： 容器将递归地尝试匹配最长的路径前缀。这个完成了 通过一次使用'/'字符作为一个目录，逐步删除路径树 路径分隔符。最长的匹配决定了所选的servlet。
安全约束在第13章和13.8.3中描述，似乎url-patterns和匹配算法与servlet的相同。
想象一下，您有一个遗留应用程序，其中JSF页面按以下方式组织： 对于每个实体类，都有一个实体名称的目录，其中包含4个JSF文件（List，edit，create，view）。 如果您想保护编辑和创建页面的访问权限，该怎么办？在我看来，你只能在url-pattern中使用'完全匹配'，所以你必须为你想要保护的每个页面写一个约束，这是一个非常冗长乏味，容易出错的活动。 此外，如果我使用路径映射规则保护整个目录（例如 / customers / * ），我无法看到任何方法来缓解该目录中特定页面的约束（例如，如果需要释放对受保护目录中页面“List”的访问权限。）
在使用Glassfish 3.1进行的实验中，我注意到这种奇怪的行为： 路径映射只有在它们与上下文根绝对时才能正常工作，因此使用jsf默认配置时，它们必须以“ / faces ”开头。如果我写 / customers / 而不是 / faces / customers / ，则不会评估安全约束。据我所知，这与12.1（上文报道）所述相反。
有人可以阐明如何有效地使用url-pattern来定义安全约束吗？ 显然，您可以将所有敏感的JSF放在“ / protected ”目录中，但这是一种非常具有侵入性的方法，可以通过安全性来破坏JSF的任何逻辑顺序。
由于 菲利普
答案 0 :(得分：1)
有人可以了解如何有效地使用url-pattern来定义安全约束吗？
我不能，经过几年的Java EE，我觉得Java EE安全约束只对身份验证有用。如果涉及授权（是被授权执行特定操作的已知实体），则此安全模型将失败，因为它过于笼统（与URL相关）。你可以看看例如春季安全。根据用例的复杂程度，您可以考虑构建自己的 - 特别是在涉及以数据为中心的安全性时（例如，只允许组织A中的用户修改组织B提供的数据）。
不是答案，但我的意见......