On 21/09/2009 01:20, Caldarale, Charles R wrote:
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Subject: Re: Security Constraint conflict
On 9/18/2009 9:47 PM, Bill Barker wrote:
I haven't checked the Servlet 3 spec, but with earlier versions,
the union process is to give you the *least* restrictive checking
(i.e. you just have to pass one constraint to pass).
With one specific exception (see below).
Peter's original constraints never mentioned anything about the GET
method on /*. Is silence consent in this scenario? I would imagine
that explicitly prohibiting PUT, DELETE, TRACE, and OPTIONS does not
tacitly allow GET. :(
Actually, the /* constraint would allow GET - as required by the spec - if it
were the only constraint. I think what's going wrong is failure to follow this
requirement from the spec (emphasis added):
"The special case of an authorization constraint that *names no roles* shall combine
with any other constraints to override their affects and cause access to be
precluded." [Servlet Specification Version 2.5 MR6, SRV.12.7.1]
Since neither constraint specifies any roles, I think the effect should be to
prevent access to /both/ *.xhtml and the PUT, DELETE, TRACE, and OPTIONS
methods.
The logical union of 'no methods' and 'some methods' is 'some methods',
isn't it? But...
...where there is such a union, the 'no methods' would need to be
converted to 'all methods' for the union to work as expected, because of
the spec definition that 'no methods' == 'all methods', won't it?
Does Tomcat do this?
But then, surely, the other side-effect of the union would be that /* is
unavailable to GET requests.
Is there actually a way for this to work as the OP wants, I'm not sure I
can see the logical way to make it work. (But then I haven't had a
coffee yet.)
p
(I'm not a lawyer, but I frequently have to play one at work :-)
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
