spring-projects / spring-projects/spring-session
HttpSessionDestroyedEvent triggered 3 times for a session logout
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 1.9k
- Forks
- 1.2k
- Avg merge
- 4h 27m
- Merged PRs (30d)
- 55
Description
While Integrating a Spring MVC application with REDIS, we noticed that HttpSessionDestroyedEvent is triggering multiple time for a single session logout(delete) activity.
Here are the dependencies I am using
- javax.servlet-api - 3.0.1
- spring mvc -5.1.9.RELEASE
- spring-session-core -2.1.8.RELEASE
- spring-session-data-redis - 2.1.8.RELEASE
- lettuce-core -5.1.8.RELEASE
- Deployment environment - Jboss EAP 7.2.2
- Redis Server - Redis Enterprise 5.4
In web.xml , I have both springSessionRepositoryFilter and springSecurityFilterChain setup with mappings.
I am using @EnableRedisHttpSession annotation in the SpringSecurityConfig and I have a DatabaseSessionRegistry which adds/delete session records entry in a table for tracking login/logout activity.
I have a custom cookie serializer bean to override the base64encoding feature in spring-session, LettuceConnectionFactory and RedisTemplate beans for establishing the connection to REDIS and a ConcurrentSessionControlAuthenticationStrategy to control concurrent logins in my application.
@Bean
public HttpSessionEventPublisher httpSessionEventPublisher() {
return new HttpSessionEventPublisher() {
ApplicationContext getContext(ServletContext servletContext) {
return SecurityWebApplicationContextUtils.findRequiredWebApplicationContext(servletContext);
}
public void sessionDestroyed(HttpSessionEvent event) {
HttpSessionDestroyedEvent e = new HttpSessionDestroyedEvent(event.getSession());
System.out.println("Publishing Event's SessionID: " + event.getSession().getId()
+ " Publishing event Timestamp: " + e.getTimestamp() + " Publishing event Source: " + e.getSource());
getContext(event.getSession().getServletContext()).publishEvent(e);
}
};
}
Here is the output I am getting for the logout
10:54:28,332 INFO [stdout] (redisMessageListenerContainer-6) Publishing Event's SessionID: fea317a0-a498-4fd4-b832-55ef687ec5b9
Publishing event Timestamp: 1568991268332 Publishing event Source: org.springframework.session.web.http.HttpSessionAdapter@3377d2f7
10:54:28,376 INFO [stdout] (redisMessageListenerContainer-6) Publishing Event's SessionID: fea317a0-a498-4fd4-b832-55ef687ec5b9
Publishing event Timestamp: 1568991268376 Publishing event Source: org.springframework.session.web.http.HttpSessionAdapter@10c90a70
10:54:28,461 INFO [xxxxxxx] (default task-2) user logging out
10:54:28,524 INFO [stdout] (redisMessageListenerContainer-6) Publishing Event's SessionID: fea317a0-a498-4fd4-b832-55ef687ec5b9
Publishing event Timestamp: 1568991268523 Publishing event Source: org.springframework.session.web.http.HttpSessionAdapter@1152cea8
Since I am depending on this event to do some cleaning operations (delete the session entry in a table ) in DatabaseSessionRegistry.removeSessionInformation(), these 3 threads will enter the method same time and one will get success and other 2 will cause a StaleStateException.
I noticed that a similar issue was raised in the past - https://github.com/spring-projects/spring-session/issues/292
Can you please take a look at this issue.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the HttpSessionEventPublisher.sessionDestroyed implementation and the DatabaseSessionRegistry.removeSessionInformation call described in the issue. Reproduce logout with the listed Spring Session, Redis, and JBoss setup, then determine why the same session ID produces three events; done means cleanup occurs without duplicate deletion or StaleStateException.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java, redis
- Domain
- authentication, backend, databases
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100