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
