Details
Description
The current configuration has all content (/*) mapped to the Acegi securityFilter in web.xml. This results in files such as /scripts/fade.js, /styles/print.css, etc. making it into the Acegi security filter chain, where they will eventually be dropped out of the security processing. No harm done, but this obscures the logs when you have debug-level logging on in Acegi to track down real security issues.
Solution:
(1) Modify filter-mappings.xml as follows:
<filter-mapping>
<filter-name>securityFilter</filter-name>
<url-pattern>/j_security_check</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>securityFilter</filter-name>
<url-pattern>*.html</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>securityFilter</filter-name>
<url-pattern>*.jsp</url-pattern>
</filter-mapping>
(2) (Optional) Simplify Acegi filter chain definitions in applicationContext-security.xml as follows:
<!-- ======================== FILTER CHAIN ======================= -->
<bean id="filterChainProxy" class="net.sf.acegisecurity.util.FilterChainProxy">
<property name="filterInvocationDefinitionSource">
<value>
CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
PATTERN_TYPE_APACHE_ANT
/j_security_check*=httpSessionContextIntegrationFilter,authenticationProcessingFilter
/**/*=httpSessionContextIntegrationFilter,remoteUserFilter,anonymousProcessingFilter,securityEnforcementFilter
</value>
</property>
</bean>
<!-- ======================== AUTHENTICATION ======================= -->
<!-- Note the order that entries are placed against the objectDefinitionSource is critical.
The FilterSecurityInterceptor will work from the top of the list down to the FIRST pattern that matches the request URL.
Accordingly, you should place MOST SPECIFIC (ie a/b/c/d.*) expressions first, with LEAST SPECIFIC (ie a/.*) expressions last -->
<bean id="filterInvocationInterceptor" class="net.sf.acegisecurity.intercept.web.FilterSecurityInterceptor">
<property name="authenticationManager"><ref local="authenticationManager"/></property>
<property name="accessDecisionManager"><ref local="accessDecisionManager"/></property>
<property name="objectDefinitionSource">
<value>
CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
PATTERN_TYPE_APACHE_ANT
/login.jsp*=ROLE_ANONYMOUS,tomcat
/logout.jsp=ROLE_ANONYMOUS,tomcat
/passwordhint.html*=ROLE_ANONYMOUS,tomcat
/signup.html=ROLE_ANONYMOUS,tomcat
/activeusers.html=admin
/clickstreams.jsp*=admin
/flushcache.html=admin
/reload.html=admin
/users.html*=admin
/viewstream.jsp*=admin
/**/*=tomcat
</value>
</property>
</bean>
**NOTE: this assumes that sample-data.xml is changed to assign the mraible ID to both the admin & tomcat roles. This seems to be typical Acegi usage. If this is not done, change each "=admin" above to "=admin,tomcat".
Solution:
(1) Modify filter-mappings.xml as follows:
<filter-mapping>
<filter-name>securityFilter</filter-name>
<url-pattern>/j_security_check</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>securityFilter</filter-name>
<url-pattern>*.html</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>securityFilter</filter-name>
<url-pattern>*.jsp</url-pattern>
</filter-mapping>
(2) (Optional) Simplify Acegi filter chain definitions in applicationContext-security.xml as follows:
<!-- ======================== FILTER CHAIN ======================= -->
<bean id="filterChainProxy" class="net.sf.acegisecurity.util.FilterChainProxy">
<property name="filterInvocationDefinitionSource">
<value>
CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
PATTERN_TYPE_APACHE_ANT
/j_security_check*=httpSessionContextIntegrationFilter,authenticationProcessingFilter
/**/*=httpSessionContextIntegrationFilter,remoteUserFilter,anonymousProcessingFilter,securityEnforcementFilter
</value>
</property>
</bean>
<!-- ======================== AUTHENTICATION ======================= -->
<!-- Note the order that entries are placed against the objectDefinitionSource is critical.
The FilterSecurityInterceptor will work from the top of the list down to the FIRST pattern that matches the request URL.
Accordingly, you should place MOST SPECIFIC (ie a/b/c/d.*) expressions first, with LEAST SPECIFIC (ie a/.*) expressions last -->
<bean id="filterInvocationInterceptor" class="net.sf.acegisecurity.intercept.web.FilterSecurityInterceptor">
<property name="authenticationManager"><ref local="authenticationManager"/></property>
<property name="accessDecisionManager"><ref local="accessDecisionManager"/></property>
<property name="objectDefinitionSource">
<value>
CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
PATTERN_TYPE_APACHE_ANT
/login.jsp*=ROLE_ANONYMOUS,tomcat
/logout.jsp=ROLE_ANONYMOUS,tomcat
/passwordhint.html*=ROLE_ANONYMOUS,tomcat
/signup.html=ROLE_ANONYMOUS,tomcat
/activeusers.html=admin
/clickstreams.jsp*=admin
/flushcache.html=admin
/reload.html=admin
/users.html*=admin
/viewstream.jsp*=admin
/**/*=tomcat
</value>
</property>
</bean>
**NOTE: this assumes that sample-data.xml is changed to assign the mraible ID to both the admin & tomcat roles. This seems to be typical Acegi usage. If this is not done, change each "=admin" above to "=admin,tomcat".
<!-- ======================== FILTER CHAIN ======================= -->
<bean id="filterChainProxy" class="net.sf.acegisecurity.util.FilterChainProxy">
<property name="filterInvocationDefinitionSource">
<value>
CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
PATTERN_TYPE_APACHE_ANT
/j_security_check*=httpSessionContextIntegrationFilter,authenticationProcessingFilter
/scripts/validator.jsp=
/**/*=httpSessionContextIntegrationFilter,remoteUserFilter,anonymousProcessingFilter,securityEnforcementFilter
</value>
</property>
</bean>
I would have preferred to exclude it at the filter-mappings.xml (later merged into web.xml) level, but there doesn't appear to be an easy way to do this.