Head First Servlets and JSP, 2nd Edition

Dueling <auth-constraint> elements

If two or more <security-constraint> elements have partially or fully overlapping <web-resource-collection> elements, here’s how the container resolves access to the overlapping resources. A and B refer to the DD on the previous page.

Rules for interpreting this table:

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.

Note

When two different nonempty <auth-constraint> elements apply to the same constrained resource, access is granted to the union of all roles from both of the <auth-constraint> elements.

There are no Dumb Questions

Q:	Q: I understand that putting in an empty <auth-constraint/> element tells the Container that NOBODY from any role can access the constrained resource. But I don’t understand WHY you would ever do that. What good is a resource that nobody can access?
A:	A: When we said, “NOBODY”, we meant, “Nobody from OUTSIDE the web app”. In other words, a client can’t access the constrained resource, but another part of the web app can ...