On 20/03/2020 22:18, James H. H. Lampert wrote: > 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: > >> <security-constraint> >> <web-resource-collection> >> <web-resource-name>Suppress OPTIONS</web-resource-name> >> <url-pattern>/*</url-pattern> >> <http-method>OPTIONS</http-method> >> </web-resource-collection> >> <auth-constraint /> >> </security-constraint> > > Would that (1) block OPTIONS globally, and (2) *not* get into any fights > with any of the individual webapp security constraints?
Yes. The short version of 13.8 for this specific scenario is that all the constraints for the same method / URL pair are combined and, if one of those constraints contains an empty auth-constraint, that takes priority and access is blocked. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
