Spring-session: When Spring Session combined with Spring Security is used, timeout cannot be detected.

[btkukinom]

We are using spring-session and spring-security.
The problem occured during version upgrade.

Timeout cannot be detected in version A.
Previously, we have used spring-session and spring-security combination of version B.

version A
spring-boot-starter-redis:2.0.4.RELEASE
spring-session-data-redis:2.0.5.RELEASE

• spring-session-core: 2.0.5.RELEASE
  spring-security-web:5.0.7.RELEASE

version B
spring-boot-starter-redis:1.5.7.RELEASE
spring-session: 1.3.1.RELEASE
spring-security-web: 4.2.4.RELEASE

In version B, SessionManagementFilter.dofilter() of Spring Security was able to detect the timeout but,
timeout cannot be detected in version A.

SessionManagementFilter.dofilter()

                if (request.getRequestedSessionId() != null
                        && !request.isRequestedSessionIdValid()) {
                    if (logger.isDebugEnabled()) {
                        logger.debug("Requested session ID "
                                + request.getRequestedSessionId() + " is invalid.");
                    }

                    if (invalidSessionStrategy != null) {
                        invalidSessionStrategy
                                .onInvalidSessionDetected(request, response);
                        return;
                    }
                }

We think that the return value of request.getRequestedSessionId() is different for each version.
※SessionRepositoryFilter$SessionRepositoryRequestWrapper.getRequestedSessionId()

version A : null
version B : session ID

Does it work as planned ?
Could you tell me how to detect the timeout ?

[vpavic]

I think this is related to the change we made to Spring Session 2.0 in #906. As a part of that we started validating the requested session id against the session store, which as a consequence made it possible to return null. Looking at the HttpServletRequest#getRequestedSessionId it would appear to me that we might be breaking that contract now - what are your thoughts on this @rwinch?

[rwinch]

If none match couldn't we just return the first one?

[vpavic]

Yes, I guess we can do that.

[vpavic]

@btkukinom This is now fixed in master and backported to 2.0.x via #1236. If you could give 2.1.1.BUILD-SNAPSHOT or 2.0.8.BUILD-SNAPSHOT a spin, that would be highly appreciated.

[btkukinom]

@vpacic I understood. Thank you.

[btkukinom]

@vpavic

I am sorry but please let me confirm.

Is there any problem with the operation of the first request with this correction method?

SessionRepositoryFilter.getRequestedSession() is getting called before SessionRepositoryFilter.getRequestedSessionId()is called.
※HttpSessionSecurityContextRepository.loadContext(HttpRequestResponseHolder) etc. are called.

I think that even in case of first request, the session ID is returned resulting in timeout.
In case of first request, it is expected that the client will return null because the session ID is not specified.

[vpavic]

Yes, if the request didn't present a session id then a null will be returned as per HttpServletRequest.html#getRequestedSessionId javadoc.

In case session id was presented, we're either return the valid one (as we already did), or the first one that was presented (we've been returning null in 2.0.x in this scenario).

[btkukinom]

Will requestedSessionId be updated at the time of calling getRequestedSession() ?

1. GetRequestedSession() is called by another filter.(example: HttpSessionSecurityContextRepository.loadContext(HttpRequestResponseHolder) etc)
2. SessionManagementFilter calls getRequestedSessionId () .

In this case, I think that the return value of 2. in the case of the first request must be null .
However, if the current method, the session ID is the return value?

[vpavic]

Did you take a look at the commit that resolved this issue - 717e16c?

In our HttpServletRequest.html#getRequestedSessionId implementation, we actually call #getRequestedSession() session internally and cache the result so that the subsequent invocations within the lifecycle of the same request don't have to hit the session store again to validate the session existence.

We released 2.1.1.RELEASE/Bean-RELEASE yesterday - did you give it a try and still have the same problem, or the additional questions you have are simply to understand how we addressed the problem?

[btkukinom]

Since I want to use spring-session-data-redis, I thought that upgrading onlyspring-sessioncan not be handled.

I extended SessionRepositoryFilter and try to do the same, but it did not work.

[vpavic]

Since I want to use spring-session-data-redis, I thought that upgrading onlyspring-sessioncan not be handled.

The spring-session-core module carries the core Spring Session components and infrastructure, like SessionRepositoryFilter. Other modules, such as spring-session-data-redis pull this core module as a transitive dependency. Both spring-session-core and spring-session-data-redis are produced by this repository and are released together.

[btkukinom]

Sorry for being late.

I was able to confirm that it works well. Thank you very much.

[vpavic]

Thanks for following up @btkukinom!