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.
The following rules for <auth-constraint> are listed in HFS&J where two or more <security-constraint> elements specify overlapping resources:
1. When combining individual role names, all of the role names listed will be allowed.
2. A role name of "*" combines with anything else to allow access to everybody.
3. An empty <auth-constraint> tag combines with anything else to allow access to nobody! In other words, an empty <auth-constraint> is always the final word!
4. If one of the <security-constraint> elements has no <auth-constraint> element, it combines with anything else to allow access to everybody.
I'm detecting some contradiction here. There are three different things that claim to combine with anything else to provide varying access. Given the emphasis (!, etc.), I assume that an empty <auth-constraint> tag wins the war of the contradicting "combines with anything else" phrases. What's the actual scoop?
For the most part, I like this book. I am using the first edition. Is there an errata for this edition (besides the next edition)?
I haven't got the book myself, but I must admit that it is written in a difficult way. The thing to grasp is that those rules apply when two security constraints are set-up for the same resource Let me rephrase the most important rules in another way:
No <auth-constraint> means everybody is allowed to access the resource: even the people who are not authenticated (i.e. not logged in, not known to the wep-app)
The <auth-constraint> element might be present in the security constraint, but with no role names listed. This means nobody is allowed
When more than one constraint is set for the same resource: the no-value authority is overriding
The <auth-constraint> element is present with a special role name of "*". All the roles are allowed access
Does this make things clearer?
Joined: Dec 15, 2005
That helps. So I'd expect that when I have two security constraints set-up for the same resource and one has:
and the other one has:
then the latter (access to no one) overrides the first.
Is that correct?
Creator of Enthuware JWS+ V6