tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Funk <funk...@apache.org>
Subject Re: Security Constraint conflict
Date Fri, 18 Sep 2009 17:04:49 GMT
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message