By the way, this works as we expected in Websphere and WebLogic.
On Fri, Sep 18, 2009 at 3:34 PM, Peter Holcomb <peter.holc...@gmail.com> wrote: > Tim, > > Thanks for your response. I've read through the example in 13.7.2 of > the spec but I don't think I'm understanding how the union works. > According to my thought process, the url patterns are: > > *.xhtml - access precluded > > /* PUT,DELETE,TRACE,OPTIONS - access precluded > > How does the unioning of those values cause *.xhtml to be open to GET? > Are you saying I need to change the /* to *.xhtml in the constraint > with the http-methods? > > Peter Holcomb > http://www.halfslide.com > > > > On Fri, Sep 18, 2009 at 12:04 PM, Tim Funk <funk...@apache.org> wrote: >> See 13.8.1 of the servlet spec. >> >> The result in is unioning all the constraints together for one that passes >> >> It might be easier to write a filter to implement the restriction that only >> GET/POST/HEAD is allowed. >> >> -Tim >> >> Peter Holcomb wrote: >>> >>> We have a situation where we recently introduced a new security >>> constraint into our configuration that has caused a conflict with our >>> previous constraint. Here's our current configuration: >>> >>> <security-constraint> >>> <display-name>Restrict access to XHTML pages</display-name> >>> <web-resource-collection> >>> <web-resource-name>Restrict access to XHTML pages</web-resource-name> >>> <url-pattern>*.xhtml</url-pattern> >>> </web-resource-collection> >>> <auth-constraint> >>> <description>With no roles defined, no access granted</description> >>> </auth-constraint> >>> </security-constraint> >>> >>> <!-- restrict HTTP protocol methods that are not needed --> >>> <security-constraint> >>> <web-resource-collection> >>> <web-resource-name>Protected Context</web-resource-name> >>> <url-pattern>/*</url-pattern> >>> <http-method>PUT</http-method> >>> <http-method>DELETE</http-method> >>> <http-method>TRACE</http-method> >>> <http-method>OPTIONS</http-method> >>> </web-resource-collection> >>> <auth-constraint /> >>> </security-constraint> >>> >>> The purpose of the first constraint is to restrict access to all >>> .xhtml documents. This was our original configuration and has been >>> working. The second constraint was put in place in order to block >>> methods that we do not use (HTTP PUT, DELETE, TRACE, ect...). This >>> constraint has had the effect of causing our .xhtml documents to now >>> be accessible. You can point your browser to an .xhtml page and grab >>> it. When we remove the second constraint, the .xhtml files are once >>> again inaccessible. What are we doing wrong? >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
