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

Posted 2023-02-26

【中文标题】Web.xml：为啥安全约束中 url 模式的灵活性如此之差？

【英文标题】：Web.xml: why so poor flexibility for url-patterns in security contraints ?Web.xml：为什么安全约束中 url 模式的灵活性如此之差？

【发布时间】：2011-11-01 04:56:15

【问题描述】：

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

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

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 的任何逻辑顺序。

谢谢 菲利波

【参考方案1】：

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

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

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

【讨论】：

完成我之前的评论。在这里link我找到了一些关于Web应用程序安全的教程，它们都使用了容器认证和授权机制。我开始认为，如果您无法将它们改编成真实案例，那么这些教程完全是在浪费时间。我希望找到使用容器授权的人，但似乎每个人都依赖第三方库来确保安全......我错了吗？？

@Filippo：我认为这些教程值得一看。今天使用了授权（我也使用了它），我只是体验到在某个时间点你到了一个点，它不再足够了......例如数据级安全。因此，您必须决定从 JEE 授权开始是否有意义。请记住，身份验证很好。