Http Session Invalidate vs Http Session Timeout.

[govindan]

Background :

We have a class that listens for HttpSessionDestroyedEvent Spring event from Acegi (version 0.8.1)

When a User logs out -

1) HttpSessionDestroyedEvent is fired, 2) We capture the event and grab the SecureContext [SecureContext context = SecureContextUtils.getSecureContext();], 3) Grab the principal from the SecureContext 4) And perform some clean up business logic operations based on the principal instance.

The Problem :

When a user explicitly logs out (by clicking the logout button), we invalidate the session, the HttpSessionDestroyedEvent is fired and the above logic works great.

However, on Http Session timeouts, even though a HttpSessionDestroyedEvent is fired, we run into an exception getting the SecureContext.

This is the Exception :

DEBUG Exception getting the context -java.lang.IllegalStateException: ContextHolder invalid: 'null': are your filters ordered correctly? HttpSessionContextIntegrationFilter should have already executed by this time (look for it in the stack dump below)

This is the stack trace :

2005-10-24 20:27:22,855 DEBUG net.sf.acegisecurity.context.security.SecureContex tUtils.getSecureContext(SecureContextUtils.java:38 )
2005-10-24 20:27:22,855 DEBUG com.galt.ldn.security.AuthenticationListener.onApp licationEvent(AuthenticationListener.java:70)
2005-10-24 20:27:22,855 DEBUG org.springframework.context.event.SimpleApplicatio nEventMulticaster.multicastEvent(SimpleApplication EventMulticaster.java:68)
2005-10-24 20:27:22,855 DEBUG org.springframework.context.support.AbstractApplic ationContext.publishEvent(AbstractApplicationConte xt.java:218)
2005-10-24 20:27:22,855 DEBUG net.sf.acegisecurity.ui.session.HttpSessionEventPu blisher.sessionDestroyed(HttpSessionEventPublisher .java:104)
2005-10-24 20:27:22,856 DEBUG org.mortbay.jetty.servlet.AbstractSessionManager$S ession.invalidate(AbstractSessionManager.java:627)
2005-10-24 20:27:22,856 DEBUG org.mortbay.jetty.servlet.AbstractSessionManager.s cavenge(AbstractSessionManager.java:429)
2005-10-24 20:27:22,856 DEBUG org.mortbay.jetty.servlet.AbstractSessionManager.a ccess$100(AbstractSessionManager.java:47)
2005-10-24 20:27:22,856 DEBUG org.mortbay.jetty.servlet.AbstractSessionManager$S essionScavenger.run(AbstractSessionManager.java:46 2)

Question :

why are we seeing this exception only on Session Timeouts and not on Explicit Session Invalidation ? Whats the solution ?

Is there any other way to get at the user associated with the destroyed Http Session without having to get the SecureContext instance ?

Thanks. Any help greatly appreciated.

[Ben Alex]

About a week ago I refactored concurrent login support and provided lots of extra hooks and improved encapsulation. You might want to check it out from CVS and see if it needs your needs.

[deenar]

Hi

I am trying to log the logout events (either explicit or via timeouts) in our application. I am facing the same problem that govindan has reported. We are using version 1.05 of acegi.

On Http Session timeouts, even though a HttpSessionDestroyedEvent is fired, there a security context present, but no authentication details (context.getAuthentication() == null).


Order of filters is

/**=httpSessionContextIntegrationFilter, exceptionTranslationFilter, ntlmFilter, filterSecurityInterceptor

web.xml contains

<!-- Setup ACEGI to subscribe to http session events in the web context -->
<listener>
<listener-class>
org.acegisecurity.ui.session.HttpSessionEventPubli sher
</listener-class>
</listener>

Ben mentions about checking the order of filters! Can anyone help as to what i should be looking for? I am also not sure how the ConcurrentLogin support and this is related. I do not need or use any of the concurrent login functionality.

[Luke Taylor]

The concurrent login support is relevant because it maintains a registry of sessions and user information so allows you to match up users with sessions even when there is no security context available:

http://static.springframework.org/sp...istryImpl.html

[dyn]

The concurrent login support is relevant because it maintains a registry of sessions and user information so allows you to match up users with sessions even when there is no security context available:

The catch seems to be that once we get the HttpSessionDestroyedEvent, it's already too late as SessionRegistry has been cleaned out since then.

I'm trying to achieve the same as the guys above: set a "logout-like" date on session timeouts in the database. Unfortunately I have no idea how to get hooked to run code on a session timeout before Spring Security wipes the session from the SessionRegistry.

Any pointers?

[dyn]

Additionally, I cannot even get around the problem by registering a separate HttpSessionListener, as Spring Security finished all the destructive work before my own listener gets a chance to react..

So the question remains, which hook can I use in Spring Security to run any custom code on http session timeouts *and* know the principal who's session is being destroyed?

Thanks in advance!

[deenar]

I have found a couple of solutions to this issue
1)
i) Add HttpSessionAttributeListener to web.xml
ii) log logout events when ACEGI_SECURITY_CONTEXT is removed from the session.

2) or in your application listener when handling HttpSessionDestroyedEvent
i) extract user name from the session object. this is removed after security context org.acegisecurity.ui.webapp.AuthenticationProcessi ngFilter.ACEGI_SECURITY_LAST_USERNAME_KEY
This does seem to work. Not sure if this the right way to log logout events or if there is a better alternative?

Deenar