Rob Winch

It seems like this is the change that added the invalidation 6d027900ee3a1567a5bd95c028b2be16ea503a2c I'm not exactly sure all the history here. What are your thoughts @vpavic

Thanks for the report. I haven't had time to look into this in detail, but based on your description this does seem like a problem. Would either of you be...

@sc-moonlight Thanks for the PR. I'm not sure how this would work since the `DefaultCookieSerializer` strips the jvm route off before it is handed back to the `CookieHttpSessionStrategy`

@sc-moonlight Thanks for the explanation. This makes sense now. I'd prefer if the Filter is not aware of the JVM route. We also need to ensure that we are passive...

@sc-moonlight I mean that when users update they should be able to do so without any changes to their existing code. This means interfaces cannot have new methods, remove methods,...

@sc-moonlight Thanks for the updates. It seems like we have some workarounds for this at least. We will have to look into figuring this out in an upcoming release.

Spring Session does not offer this out of the box. However, I'm curious why you want this feature. Spring Session will not obtain the session unless HttpServletRequest.getSession() is invoked. This...

I think I see why this is a problem now. I created https://github.com/spring-projects/spring-session/issues/278 to address this. In the meantime, if you are already using Spring Security, you could decorate the...

In general if neither `HttpServletRequest.getSession()` or `HttpServletRequest.getSession(boolean)` are invoked, then Spring Session will not perform any lookups. In order to make this troubleshooting easier, I went ahead and created #323

@hlassiege This change is currently scheduled for 1.3.0.M1 (which is not released yet). In the meantime, you can either use Spring Security's FilterChainProxy or create your own version of it.