1.>In the servlet spec. (page 97) it says:
A security constraint that does not contain an authorization constraint shall combine with authorization constraints that name or imply roles to allow unauthenticated access.
But when I implement this the request is still being authenticated...My DD reads:
2.> In the spec(page 98) it says (and so does HFSJ) :
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.
Now when my DD reads (here I'm showing only the relevant parts) :
it obeys the spec. and does not allow access to any one in any role...
BUT if I just change the order of the 2 <security-constraint> elements in the DD as shown below then it allows any body with role "Admin"
3.> I'm gettin similar things on changing the order with other combos as well...
The tomcat-users.xml reads
Could anybody please try it out and confirm this....I'm really confused....Does the order really matter?
2. Nobody has access, in both cases, whatever the order is.
In any case, you should not spend too much time on this matter, you might have some caching problem or something related to the container.
I personaly hate that part of the deployment because it makes you waste a lot of time figuring out what could possibly be wrong.
1.> any 2 <security-constraint> elements with non-empty <auth-constraint> sub-elements(including one with <role-name>*</role-name> --> union of the 2
2.> <security-constraint> with no <auth-constraint> sub-element with any other <security-constraint> element(except one with <auth-constraint/> --> unauthenticated access
3.> <security-constraint> with <auth-constraint/> sub-element with any other <security-constraint> element--> no access to any one
Am I right?
I thought I had the answer. You are using the same web-resource-name SomeStuff for both web-resource-collections. This name should be unique. I thought this was why one definition was overwriting to other... But that didn't work out.
So... Tomcat doesn't seem to adhere to this bit of the spec and order does matter?! Most disturbing in my view. A Tomcat implementation bug? This does not help me committing this rule to memory
[ December 12, 2006: Message edited by: Johan Pelgrim ]