Webwork+Velocity+Acegi config

Honestly, it's really a no-brainer. As what other Acegi's advocates are talking about, that Acegi should work with any frameworks. That's correct and adding to that, there's isn't much to code. I experienced getting some surprisingly erratic redirection behaviours after login. But I know there's nothing wrong with controller(action) classes so I was firm about my suspicion that what was happening was just a misconfiguration on my context files. The assumption was right. After following tightly the Contacts example, there's something that needs to be modified in the redirection if anyone intends to use Webwork+Velocity with Acegi Security framework.

Listing 1: applicationContext-acegi-security.xml

<!-- ===================== HTTP REQUEST SECURITY ==================== -->

<bean id="securityEnforcementFilter"
<property name="filterSecurityInterceptor"><ref
<property name="authenticationEntryPoint"><ref

<bean id="authenticationProcessingFilter"
<property name="authenticationManager">
<ref bean="authenticationManager"/>
<property name="authenticationFailureUrl">
<property name="defaultTargetUrl"><value>/readuser.action</value></property>
<property name="filterProcessesUrl"><value>/j_acegi_security_check</value></property>
<property name="rememberMeServices"><ref local="rememberMeServices"/></property>

<bean id="authenticationProcessingFilterEntryPoint"
<!--<property name="loginFormUrl"><value>/acegilogin.jsp</value></property>-->
<property name="loginFormUrl"><value>/login.vm</value></property>
<property name="forceHttps"><value>false</value></property>

<bean id="httpRequestAccessDecisionManager"
<property name="allowIfAllAbstainDecisions"><value>false</value></property>
<property name="decisionVoters">
<ref bean="roleVoter"/>

<!-- 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 bean="authenticationManager"/></property>
<property name="accessDecisionManager"><ref local="httpRequestAccessDecisionManager"/></property>
<property name="objectDefinitionSource">


From the "filterInvocationInterceptor" id, I removed the "/**=ROLE_USER" and replace it with my actual pattern based that is also the default redirection URL if authentication is successful. This reduces the "candidates" within the filter invocation interception to be matched.

Acegi Security is a very comprehensive security framework that is usable to almost any applications including non-web apps(Swing, SWT etc.) and is straightforward to customize. I don't see any reason why would anyone build an authentication and ACL framework from scratch again.


Anonymous said…
I like this blog is fantastic, is really good written. Congratulation. Do you want to see something more? Read it...: Costa Rica is a country with a extremely sense of freedom. The landscapes are for much the most green in whole center america.The chances of investement are way to high, the average of Americans, European and people of the entire planet who is buying here is up in the sky !!!
Great investment opportunity in Costa Rica: condos, costa rica real estate, costa rica property. Visit us for more info at: http://www.jaco-bay.com/

Popular Posts