On 3/18/20 4:03 AM, Mark Thomas replied to my questions:

But I'm not sure (1) how security constraints interact with other
security constraints, and

See section 13.8.1 of the Servlet 4.0 spec.

(2) whether they can go in the conf/web.xml as
well as individual webapps' web.xml files.

Yes they can.

Dear Mr. Thomas, et al.:

Ok. I've finally gotten back to this, and I've found a copy of the Servlet 4.0 spec, and read the entire 13.8 section.

I'm not yet clear on how they interact with each other if they exist at both the conf/web.xml level and the individual webapp level.

Given a Tomcat server with several webapps running, including multiple copies of the same webapp (call it A), each accessing different underlying resources.

Each copy of A has this:
<security-constraint> <web-resource-collection> <web-resource-name>Logs</web-resource-name> <description>Logs</description> <url-pattern>/logs/*</url-pattern> <url-pattern>/logs.jsp</url-pattern> </web-resource-collection> <auth-constraint /> </security-constraint>

The manager and host-manager have their "out-of-the-box" security constraints.

Another specialized webapp (call it "S") has no security constraints in its web.xml.

There is also a context that consists only of static content, with no web.xml, and therefore no security constraints of its own.

And conf/web.xml has no security constraints.

Now, suppose I were to put this into conf/web.xml:

  <web-resource-name>Suppress OPTIONS</web-resource-name>
 <auth-constraint />

Would that (1) block OPTIONS globally, and (2) *not* get into any fights with any of the individual webapp security constraints?


To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to