Acegi goes into an infinite loop

[dcdalee]

Hello,

I've been having a peculiar problem with Acegi in our web application. To give you a little bit of context, it's a web app built on Spring and it runs in Tomcat. The problem occurs when an administrator suspends a user account while the user is logged in. This effectively changes the "enabled" flag in the database. It also evicts the user object from the cache, forcing Acegi to authenticate the user against the database instead of the cache. This throws a DisabledException error and the SecurityEnforcementFilter tries to redirect the user back to the authentication entry point which is the expected behavior. But this causes the application to go into a loop, hosing the system.

After the user is disabled, the system tries to take the user back to the entry point which I believe is set through the loginFormUrl property of the AuthenticationProcessFilterEntryPoint bean. Now I've read some posts here that say that this loginFormUrl must not be defined as a secure resource in the objectDefinitionSource of the filterInvocationInterception bean. Is this what's causing the infinite loop? I've examined the source code and I can't seem to find any potential for infinite loops when an AuthenticationException gets thrown.

Any insight would be much appreciated.

Thanks.

[Ben Alex]

Generally we recommend anonymous authentication be used, with your login form URL should being defined with a ROLE_ANONYMOUS configuration attribute. See the Contacts Sample for an example. Failing this working, please post your DEBUG level logs showing the infinite loop, and your FilterSecurityInterceptor bean configuration.

[dcdalee]

Thank you Ben for your reply. It seems that moving the login page out of the objectDefinitionSource do the trick. But I still don't know why it has to be out of the objectDefinitionSource even when it's defined as ROLE_ANONYMOUS accessible.

Yes, I've looked at the Contacts Sample app and I originally made the login form accessible by ROLE_ANONYMOUS. But when a user was disabled in the middle of the session by an admin and the user attempted to access a secured resource, Acegi threw a DisabledException and tried to redirect the user to the entry point but this was going on in a loop. I've also tried using the exceptionMapping property but to no avail. One interesting thing I noticed is this debug message:

2005-11-22 10:43:25,693 DEBUG http-8080-Processor25 net.sf.acegisecurity.providers.anonymous.Anonymous ProcessingFilter - ContextHolder not replaced with anonymous token, as ContextHolder already contained: 'net.sf.acegisecurity.providers.UsernamePasswordAu thenticationToken@39bc82:

Which I take it as saying that the user, after being disabled and is in the process of being reauthenticated by Acegi, does not have the ROLE_ANONYMOUS privilege and therefore is failing.

I've recreated the error and attached the debug log as well as the FilterSecurityInterceptor bean config. I apologize but I had to censor the links and roles with "****" before posting it.

Thanks and I look forward to your reply.

[Ben Alex]

Seems like we need to catch any AuthenticationException and remember to clear the SecurityContextHolder before calling the AuthenticationEntryPoint from SecurityEnforcementFilter. Would you mind logging a JIRA issue for this and attaching your bug report so there is proper tracking?

[dcdalee]

No problem

[grasshopper]

i have the exact same problem, how can i track when the fix is done?
my login page uses the anonymous role, but that doesnt help.
Is there a temporary fix for this?

[grasshopper]

well taking a que from your comment i have overridden sendStartAuthentication in the SecurityEnforcementFilter and I m logging off the user when an AuthenticationException is thrown. This has fixed the endless loop.
Do let me know if this sounds okkk.

[Ben Alex]

This issue was logged as SEC-112 and was fixed in CVS on 25 November 2005. It'll therefore be in 1.0.0 RC1 which will be out in a few days.