This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I'm getting results quite different from that mentioned in the servlet spec. 2.4 and the HFSJ book while combining security constraints. I'm using Tomcat 5.0.28/Win XP...Is anyone else gettin' the same thing? Here are some of the differnces:-
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?
1. Everybody has access 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.
Yes, Celinio, you're probably right....And I hate these container specific issues....just to make this sure abotu the <security-constraint> elements combination result(irrespective of order) for one final time....
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
I thought I had the answer. You are using the same web-resource-nameSomeStuff 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 ]
Johan Pelgrim, The Netherlands
SCJP 1.4, SCWCD 1.4, SCBCD 5.0