知识点
web.xml中<security-constraint> 的子元素 <http-method> 是可选的,如果没有 <http-method> 元素,这表示将禁止所有 HTTP 方法访问相应的资源。
子元素 <auth-constraint> 需要和 <login-config> 相配合使用,但可以被单独使用。如果没有 <auth-constraint> 子元素,这表明任何身份的用户都可以访问相应的资源。也就是说,如果 <security-constraint> 中没有 <auth-constraint> 子元素的话,配置实际上是不起中用的。如果加入了 <auth-constraint> 子元素,但是其内容为空,这表示所有身份的用户都被禁止访问相应的资源。
问题
对于同一个url-pattern,在web.xml出现2个<security-constraint>,一个是对该url-pattern进行了role的限制,一个没有限制role,会如何?
实践
一个是对该url-pattern进行了role的限制,即配置auth-constraint
如:
test2 /* tomcat1
一个是对该url-pattern没有进行role的限制
如:
test3 /*
对于tomcat而言,在org.apache.catalina.authenticator.AuthenticatorBase认证类中
/** * Enforce the security restrictions in the web application deployment * descriptor of our associated Context. * * @param request Request to be processed * @param response Response to be processed * * @exception IOException if an input/output error occurs * @exception ServletException if thrown by a processing element */ @Override public void invoke(Request request, Response response) throws IOException, ServletException { .... // Since authenticate modifies the response on failure, // we have to check for allow-from-all first. // boolean authRequired; if (constraints == null) { authRequired = false; } else {//有安全限制 authRequired = true; for(i=0; i < constraints.length && authRequired; i++) { if(!constraints[i].getAuthConstraint()) {//如果不需要认证限制 authRequired = false;//则不需要认证 } else if(!constraints[i].getAllRoles()) {//如果不是*,即所有角色的话 String [] roles = constraints[i].findAuthRoles(); if(roles == null || roles.length == 0) { //只要此url-pattern有一个限制没有控制角色,则满足次url-pattern的url可以被任意角色和匿名用户访问 authRequired = false;//则不需要认证 } } } } ......
结论
所以按照上面同时配置同一个url-pattern,不同安全限制,只要有一个不限制角色,则此url-pattern不受角色限制,满足次url-pattern的url可以被任意角色和匿名用户访问