tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Holcomb <peter.holc...@gmail.com>
Subject Re: Security Constraint conflict
Date Fri, 18 Sep 2009 20:46:12 GMT
By the way, this works as we expected in Websphere and WebLogic.



On Fri, Sep 18, 2009 at 3:34 PM, Peter Holcomb <peter.holcomb@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 <funkman@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>

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


Mime
View raw message