Project

General

Profile

Actions

Bug #12481

closed

When logged > 3 times, oldest session is logged out but not immediately

Added by François ARMAND almost 6 years ago. Updated almost 6 years ago.

Status:
Rejected
Priority:
N/A
Assignee:
-
Category:
Security
Target version:
Severity:
UX impact:
User visibility:
Effort required:
Priority:
0
Name check:
Fix check:
Regression:

Description

With ticket #12367 we added a correct session handling regarding spring-security. But the behaviour is strange from an user point of view, because spring-security (or jetty) does not notice immediately that a session is not valid anymore because the user log-in again (2 times).

Moreover when the session is invalidated, we get a stack-trace:

java.lang.IllegalStateException
        at org.eclipse.jetty.server.session.AbstractSession.checkValid(AbstractSession.java:109)
        at org.eclipse.jetty.server.session.HashedSession.checkValid(HashedSession.java:73)
        at org.eclipse.jetty.server.session.AbstractSession.getAttribute(AbstractSession.java:132)
        at org.springframework.security.web.context.HttpSessionSecurityContextRepository.readSecurityContextFromSession(HttpSessionSecurityContextRepository.java:148)
        at org.springframework.security.web.context.HttpSessionSecurityContextRepository.loadContext(HttpSessionSecurityContextRepository.java:87)
        at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:82)
        at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
        at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
        at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
        at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:343)
        at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:260)
        at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1288)
        at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:443)
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
        at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:532)
        at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:227)
        at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1044)
        at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:372)
        at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:189)
        at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:978)
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
        at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:193)
        at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
        at org.eclipse.jetty.server.Server.handleAsync(Server.java:409)
        at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:469)
        at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:79)
        at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667)
        at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)
        at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
        at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
        at java.lang.Thread.run(Thread.java:748)

I'm wondering if it is not the expected behavior, even if it's a very bad one. We need at least to correctly handle the exception to have a nice message in its place.


Related issues 2 (0 open2 closed)

Related to Rudder - Bug #12581: Remove max concurrent session limit to avoid denial of servicesReleasedBenoît PECCATTEActions
Related to Rudder - Bug #12367: Bad session counting block user login after three session createdReleasedVincent MEMBRÉActions
Actions #1

Updated by François ARMAND almost 6 years ago

  • Related to Bug #12581: Remove max concurrent session limit to avoid denial of services added
Actions #2

Updated by Vincent MEMBRÉ almost 6 years ago

  • Target version changed from 4.1.12 to 4.1.13
Actions #3

Updated by Benoît PECCATTE almost 6 years ago

  • Target version changed from 4.1.13 to 411
Actions #4

Updated by Benoît PECCATTE almost 6 years ago

  • Target version changed from 411 to 4.1.13
Actions #5

Updated by Benoît PECCATTE almost 6 years ago

  • Status changed from New to Rejected

Not true anymore since there is no more session limit

Actions #6

Updated by François ARMAND almost 6 years ago

  • Related to Bug #12367: Bad session counting block user login after three session created added
Actions

Also available in: Atom PDF