【问题标题】:Is it possible to enable/disable security constraints in web.xml on the basis of custom property?是否可以基于自定义属性启用/禁用 web.xml 中的安全约束?
【发布时间】:2017-10-18 17:27:59
【问题描述】:

我在 web.xml 中有以下 security-constraint 属性

<security-constraint>
    <web-resource-collection>
        <web-resource-name>TempName123</web-resource-name>
        <url-pattern>/a/b/c</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <role-name>*</role-name>
    </auth-constraint>
</security-constraint>

这里,主要要求是这个约束需要在一定的基础上加载。在安装过程中,一些用户可能会选择添加此安全性,也可能不会。

jboss/tomcat 中是否有任何基于属性的功能,当设置为 true 时,会考虑此安全约束,否则会忽略 ????

PS:每次需要添加/删除此功能时,我都会尝试避免基于文件的操作来编辑 web.xml 文件。

【问题讨论】:

标签: java tomcat jboss webserver


【解决方案1】:

在运行时更新安全约束是很罕见的。我的建议是将其嵌入到您的构建过程中,以防您需要在开发/测试期间停用安全约束。我不知道任何(指定的)运行时可配置性。

当然,当您明确标记 tomcat 时,可能有一些方法可以与 Tomcat 的 API 进行交互以实现这一点 - 我希望这完全是 Tomcat(版本)特定的,并且会惊讶地看到类似的东西这在 servlet 规范中(免责声明:我没有在那里检查过 - 很长时间没有阅读规范,这只是出于记忆和个人期望)

我一个字回答,除非有人证明我错了:

jboss/tomcat 中是否有任何基于属性的功能,当设置为 true 则考虑此安全约束,否则忽略 ????

没有

【讨论】:

  • 某些用户可能/可能不会选择具有此安全约束。所以我想,在用户机器上的应用程序部署期间,唯一的方法是以编程方式编辑web.xml 文件并使用基于文件的操作相应地添加此安全约束。
  • 您不需要手动编辑 - 您的构建系统也可能只生成两个不同版本的可部署工件。然后您可以选择要部署的版本。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2019-11-02
  • 2012-11-23
  • 2023-03-30
相关资源
最近更新 更多