Spring Sessions HttpSession unable to completely replace JSESSIONID

Question

I am looking at moving user session from the application level to a Redis instance. I believe I have everything set up correctly according to the documentation (http://docs.spring.io/spring-session/docs/current/reference/html5/#httpsession), but I'm not seeing the behavior I'm expecting and thinking that I missed a step somewhere.

The application currently uses HttpSession, so I simply added the following to the context:

<context:annotation-config/>
<util:constant static-field="org.springframework.session.data.redis.config.ConfigureRedisAction.NO_OP"/>
<beans:bean class="org.springframework.session.data.redis.config.annotation.web.http.RedisHttpSessionConfiguration"/>
<beans:bean id="jedisConnectionFactory" class="org.springframework.data.redis.connection.jedis.JedisConnectionFactory" p:host-name="HOSTNAME" p:port="6379" />

Added the following to web.xml:

<filter>
    <filter-name>springSessionRepositoryFilter</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
    <filter-name>springSessionRepositoryFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

The application builds, deploys, and loads the page fine, but when I look at the cookies on the page, I have both JSESSIONID and SESSION. JSESSIONID I know is used by Spring Security, and it looks like SESSION is used by Spring Session. When I look inside redis, it looks like SESSION is the one being stored.

Another problem is that custom session objects (added using session.setAttribute) are not showing up in the session. The only thing that shows up in the session is AFTER logging in, and is the SPRING_SECURITY_CONTEXT object. When I remove the Spring Session filter, those objects are added to the session just fine.

Is this normal behavior, or do I have some strange conflict due to my setup?

Ingres

#44304004 – Regulable

Answer 1

I had the same problem, and finally it turned out it was a result of wrong order of filters declared in my web.xml. The first filter the request was going through was spring security filter, which was setting JSESSIONID cookie in the response, and then spring session repository filter was coming into play setting its own SESSION cookie. After changing the order so that spring session repository filter performs its action first, everything works just fine.

Jumna

Confirmed that as the problem. Thanks! – Ingres

#44304004 – Regulable

Answer 2

Had the same problem. But filter ordering doesn't help.

It can be both SESSION and JSESSIONID in response when JSESSIONID passed in request and then spring session will add SESSION cookie together with provided cookie (you can clean up your cookies in your request to receive only SESSION).

The reason why it's happened in my situation is:

By default cookie is provided by application server (tomcat) and when I added spring session, cookies will be provided by spring. Default for tomcat is JSESSIONID, default for spring (DefaultCookieSerializer.class) is SESSION

To fix this I simply specified cookies name in WEB.xml:

<session-config>
    <cookie-config>
        <name>JSESSIONID</name>
    </cookie-config>
</session-config>

This will specify cookies name for both tomcat and spring session filter

Rahal

Answer 3

I had the same problem. The Problem was tomcat which would add JSESSIONID cookie in response. So I added CookieSerializer and problem resolved.

@Bean
public CookieSerializer cookieSerializer() {
    DefaultCookieSerializer serializer = new DefaultCookieSerializer();
    serializer.setCookieName("JSESSIONID"); 
    serializer.setCookiePath("/"); 
    serializer.setDomainNamePattern("^.+?\\.(\\w+\\.[a-z]+)$"); 
    return serializer;
}

Also don't forget to change context.xml in tomcat like this:

<Context cookies="false">
    ....
</Context>

Mullah