0

I have following security-constraint property in web.xml

<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>

Here, the main requirement is that this constraint needs to be loaded on certain basis. During installation, some user may chose to add this security or some may not.

Is there any property based feature in jboss/tomcat which when set to true then this security constraint is considered, otherwise ignored ????

PS: I am trying to avoid file based operations to edit web.xml file each and every time this feature needs to be added/removed.

user
  • 383
  • 1
  • 5
  • 20

1 Answers1

0

It's quite uncommon that security constraints are updated at runtime. My advice would be to embed this into your build process in case you need to deactivate security constraints during development/testing. I'm not aware of any (specified) runtime configurability.

Of course, as you tag tomcat explicitly, there might be ways to interact with Tomcat's API in order to achieve this - I'd expect this to be completely Tomcat-(version)-specific and would be surprised to see anything like this in the servlet spec (disclaimer: I haven't checked it there - didn't read the spec in a long time and this is just from memory and personal expectation)

My single word answer, unless someone proves me to be wrong:

Is there any property based feature in jboss/tomcat which when set to true then this security constraint is considered, otherwise ignored ????

No

Olaf Kock
  • 46,930
  • 8
  • 59
  • 90
  • Some user may/may not chose to have this security constraint. So I guess, during application deployment on user's machine, the only way is to edit the `web.xml` file programmatically and add this security-constraint accordingly using file-based operations. – user Oct 18 '17 at 09:32
  • You don't need to edit manually - your build system may also just produce two different versions of the deployable artifact. Then you can choose which version to deploy. – Olaf Kock Oct 18 '17 at 09:54