Changed implementation of AuthenticationProcessingFilter

[sruch]

Hi all,
After updating from acegi 1.0.0 RC2 to 1.0.0 final we recognized a change of the implementation of AuthenticationProcessingFilter.

What happend:
We wanted to have a different start page for special users after logging into the system. We wrote an extension of the AuthenticationProcessingFilter which overwrites the successfulAuthentication method. Here is the implementation...

protected void successfulAuthentication(HttpServletRequest request,
		HttpServletResponse response, Authentication authResult) throws IOException
{
	String targetUrl;
	if (authResult != null && authResult.getPrincipal() instanceof WlcClient)
	{
		WlcClient client = (WlcClient) authResult.getPrincipal();
		if (client.isUserInRole(WlcConstants.WlcRoles.ADMIN_USER))
		{
			targetUrl = request.getContextPath() + getDefaultAdminTargetUrl();
			logger
						.info("Authenticated user is an administrator... redirect to admin page ["
								+ targetUrl + "]...");
			request.getSession().setAttribute(ACEGI_SAVED_REQUEST_KEY, targetUrl);
		}
		else if (client.isUserInRole(WlcConstants.WlcRoles.WL_ADMIN_USER))
		{
			targetUrl = request.getContextPath() + getDefaultWlAdminTargetUrl();
			logger
						.info("Authenticated user is an wl-administrator... redirect to admin page ["
								+ targetUrl + "]...");
			request.getSession().setAttribute(ACEGI_SAVED_REQUEST_KEY, targetUrl);
		}
	}
	super.successfulAuthentication(request, response, authResult);
}

In acegi 1.0.0 final there was a change in the constants. The ACEGI_SECURITY_TARGET_URL_KEY no longer exists in 1.0.0 final. After reviewing we changed it to ACEGI_SAVED_REQUEST_KEY and compilation was successful.

Now we have the following exception:

java.lang.ClassCastException: java.lang.String
	org.acegisecurity.wrapper.SavedRequestAwareWrapper.<init>(SavedRequestAwareWrapper.java:88)
	sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
	sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
	java.lang.reflect.Constructor.newInstance(Constructor.java:494)
	org.acegisecurity.wrapper.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:75)
	org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
	org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:216)
	org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
	org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:195)
	org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
	org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
	org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:90)
	com.namics.publiconnect.wlc.web.filter.SiteContextFilter.doFilter(SiteContextFilter.java:91)
	org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:137)
	org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:75)
	org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:77)

Can someone explain the change or give an alternativ to implement the described requirement (different start pages depending on the user's role)?

Thanks and kind regard,
Sandro

[Luke Taylor]

I think the best option for your situation would be if we provided a protected getter method for the defaultTargetUrl and you overrode this to return a different value for your different roles (making sure that the alwaysUseDefaultTargetUrl property is set of the filter).

This seems like a reasonably small change and could provide a userful option for similar scenarios where multiple default Urls are required.

[Luke Taylor]

http://opensource.atlassian.com/proj...browse/SEC-295

[Luke Taylor]

I've made the changes to the class (in fact the accessor was already there, but I just had to make sure it was used internally).

so you should be able to use:

public String getDefaultTargetUrl() {
   Authentication authResult = SecurityContextHolder.getContext().getAuthentication();

   if (authResult != null && authResult.getPrincipal() instanceof WlcClient)
   {
      WlcClient client = (WlcClient) authResult.getPrincipal();
      if (client.isUserInRole(WlcConstants.WlcRoles.ADMIN_USER)) {
         return request.getContextPath() +getDefaultAdminTargetUrl();
      }
      
      // other cases
   }

   return super.getDefaultTargetUrl();

}

The subversion tag is 1538 so if you pick up a nightly build snapshot with this number or later this should work Ok.

[sruch]

Hi Luke,

That would be great and very helpful! I've taken the 1.0.0 tag in subversion and patched the one file with the current version in the trunk. Is this ok or do i need other dependencies?

Thank very much and best regards,
Sandro

[sruch]

Hi Luke,

I've seen in your code that you access the request object but you don't provide it in the method-signature... so it is probably better to provide a general hook-method than using the getter of an instance variable...

Bye,
Sandro

[Luke Taylor]

Hi,

That's actually a mistake, as I just copied the code from your earlier post. The default target Url should be relative to the context. The context is prepended here:

http://www.acegisecurity.org/multipr...ilter.html#389

So you only need to return "getDefaultAdminTargetUrl()" or whatever.

Luke.

[sruch]

Hi Luke,

I see... thats fine...

Now i have another question (Just to be sure i we use it correctly)?
In the prev implementation we could access the saved target url in the session as a string. Is this correct anymore? Or do we need to cast it always into a SavedRequest and therefor integrate it with the org.acegisecurity.wrapper.SecurityContextHolderAwa reRequestFilter?

Thanks and regards,
Sandro

[Luke Taylor]

You can get the Url from the saved request - see the method obtainFullRequestUrl:

http://acegisecurity.org/multiprojec...ilter.html#276

[rcastro]

I think the best option for your situation would be if we provided a protected getter method for the defaultTargetUrl and you overrode this to return a different value for your different roles (making sure that the alwaysUseDefaultTargetUrl property is set of the filter).

This seems like a reasonably small change and could provide a userful option for similar scenarios where multiple default Urls are required.

Luke, I was wondering if the same could be done with alwaysUseDefaultTargetUrl, so AbstractProcessingFilter could use the isAlwaysUseDefaultTargetUrl() method instead of the variable directly.

In my case, I want the first time a user logs in to be redirected to a welcome page, but all others should follow their target urls. In this case, my idea was to override isAlwaysUserDefaultTargetUrl() method (which is not currently called by succesfullAuthentication() in AbstractProcessingFilter) that would decide if the the filter should use the default target always (in case of first-time users) or not (in case of other users). In the former case, my getDefaultTargetUrl() would decide which welcome page is appropriate.

What do you think?

Thanks,

Rodrigo