i am combininig multiple <security-constraint> and wildcard pattern. The
result is a bit confusing.
only and single <security-constraint> def:
===
<security-constraint>
<web-resource-collection>
<web-resource-name>HTMLManger and Manager command</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
===
Above gives me access to all ressources.
Now adding another constraint disallows the 'admin' to access ressource
/foo:
===
<security-constraint>
<web-resource-collection>
<web-resource-name>HTMLManger and Manager command</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
<security-constraint>
<web-resource-collection>
<web-resource-name>HTMLManger and Manager command</web-resource-name>
<url-pattern>/foo</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>other</role-name>
</auth-constraint>
</security-constraint>
===
This is counterintuitive, I would still expect 'admin' to access all
ressources, because it has /* wildcard.
After debugging tomcat confirms, adding constraints is side-effecting
exististing constraints.
When reading the servlet specification SRV.12.8.1 it mentions an union
operation of multiple <security-constraint>. But to me above behaviour looks
more like a difference operation (the 2nd security constraint is removing a
right from the 1st one).
Or maybe I am reading something wrong...?
thanks.
-----
manuel aldana
aldana((at))gmx.de
software-engineering blog: http://www.aldana-online.de
--
View this message in context:
http://old.nabble.com/security%2C-web.xml%3A-multiple-%3Csecurity-constraint%3E-override-wildcard-%3Cweb-resource-collection%3E-tp28219182p28219182.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
