Guide to Spring Session

Spring Session Introduction

Posted by Mr.Humorous 🥘 on January 21, 2019

1. Overview

Spring Session has the simple goal of free up session management from the limitations of the HTTP session stored in the server.

The solution makes it easy to share session data between services in the cloud without being tied to a single container (i.e. Tomcat). Additionally, it supports multiple sessions in the same browser and sending sessions in a header.

In this article, we’ll use Spring Session to manage authentication information in a web app. While Spring Session can persist data using JDBC, Gemfire, or MongoDB, we will use Redis.

For an introduction to Redis check out this article.

2. A Simple Project

Let’s first create a simple Spring Boot project to use as a base for our session examples later on:

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>1.4.0.RELEASE</version>
    <relativePath/>
</parent>

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-security</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-test</artifactId>
        <scope>test</scope>
    </dependency>
</dependencies>

Our application runs with Spring Boot and the parent pom provides versions for each entry.

Let’s also add some configuration properties for our Redis server in application.properties:

spring.redis.host=localhost
spring.redis.port=6379

3. Spring Boot Configuration

First, let’s demonstrate configuring Spring Session with Boot.

3.1 Dependencies

Add these dependencies to our project:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.session</groupId>
    <artifactId>spring-session</artifactId>
</dependency>

We are using the boot parent pom to set the versions here, so these are guaranteed to work with our other dependencies.

3.2. Spring Session Configuration

Now let’s add a configuration class for Spring Session:

@Configuration
@EnableRedisHttpSession
public class SessionConfig extends AbstractHttpSessionApplicationInitializer {
}

4. Standard Spring Config (no Boot)

4.1. Dependencies

First, if we’re adding spring-session to a standard Spring project, we’ll need to explicitly define:

<dependency>
    <groupId>org.springframework.session</groupId>
    <artifactId>spring-session</artifactId>
    <version>1.2.2.RELEASE</version>
</dependency>
<dependency>
    <groupId>org.springframework.data</groupId>
    <artifactId>spring-data-redis</artifactId>
    <version>1.5.0.RELEASE</version>
</dependency>

4.2. Spring Session Configuration

Now let’s add a configuration class for Spring Session:

@Configuration
@EnableRedisHttpSession
public class SessionConfig extends AbstractHttpSessionApplicationInitializer {
    @Bean
    public JedisConnectionFactory connectionFactory() {
        return new JedisConnectionFactory();
    }
}

As you can see the differences are minimal – we just have to now define our JedisConnectionFactory bean explicitly – Boot does it for us.

In both types @EnableRedisHttpSession and the extension of AbstractHttpSessionApplicationInitializer will create and wire up a filter in front of all our security infrastructure to look for active sessions and populate the security context from values stored in Redis.

Let’s now complete this application with a controller and the security config.

5. Application Configuration

Navigate to our main application file and add a controller:

@RestController
public class SessionController {
    @RequestMapping("/")
    public String helloAdmin() {
        return "hello admin";
    }
}

This will give us an endpoint to test.

Next, add our security configuration class:

@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {

    @Autowired
    public void configureGlobal(AuthenticationManagerBuilder auth) throws Exception {
        auth
          .inMemoryAuthentication()
          .withUser("admin").password("password").roles("ADMIN");
    }

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
          .httpBasic().and()
          .authorizeRequests()
          .antMatchers("/").hasRole("ADMIN")
          .anyRequest().authenticated();
    }
}

This protects our endpoints with basic authentication and sets up a user to test with.

6. Test

Finally, let’s test everything out – we’ll define a simple test here that’s going to allow us to do 2 things:

  • consume the live web application
  • talk to Redis

Let’s first set things up:

public class SessionControllerTest {

    private Jedis jedis;
    private TestRestTemplate testRestTemplate;
    private TestRestTemplate testRestTemplateWithAuth;
    private String testUrl = "http://localhost:8080/";

    @Before
    public void clearRedisData() {
        testRestTemplate = new TestRestTemplate();
        testRestTemplateWithAuth = new TestRestTemplate("admin", "password", null);

        jedis = new Jedis("localhost", 6379);
        jedis.flushAll();
    }
}

Notice how we’re setting up both of these clients – the HTTP client and the Redis one. Of course, at this point the server (and Redis) should be up and running – so that we can communicate with them via these tests.

Let’s begin by testing that Redis is empty:

@Test
public void testRedisIsEmpty() {
    Set<String> result = jedis.keys("*");
    assertEquals(0, result.size());
}

Now test that our security returns a 401 for unauthenticated requests:

@Test
public void testUnauthenticatedCantAccess() {
    ResponseEntity<String> result = testRestTemplate.getForEntity(testUrl, String.class);
    assertEquals(HttpStatus.UNAUTHORIZED, result.getStatusCode());
}

Next, we test that Spring Session is managing our authentication token:

@Test
public void testRedisControlsSession() {
    ResponseEntity<String> result = testRestTemplateWithAuth.getForEntity(testUrl, String.class);
    assertEquals("hello admin", result.getBody()); //login worked

    Set<String> redisResult = jedis.keys("*");
    assertTrue(redisResult.size() > 0); //redis is populated with session data

    String sessionCookie = result.getHeaders().get("Set-Cookie").get(0).split(";")[0];
    HttpHeaders headers = new HttpHeaders();
    headers.add("Cookie", sessionCookie);
    HttpEntity<String> httpEntity = new HttpEntity<>(headers);

    result = testRestTemplate.exchange(testUrl, HttpMethod.GET, httpEntity, String.class);
    assertEquals("hello admin", result.getBody()); //access with session works worked

    jedis.flushAll(); //clear all keys in redis

    result = testRestTemplate.exchange(testUrl, HttpMethod.GET, httpEntity, String.class);
    assertEquals(HttpStatus.UNAUTHORIZED, result.getStatusCode());
    //access denied after sessions are removed in redis
}

First, our test confirms that our request was successful using the admin authentication credentials.

Then we extract the session value from the response headers and use it as our authentication in our second request. We validate that, and then clear all the data in Redis.

Finally, we make another request using the session cookie and confirm that we are logged out. This confirms that Spring Session is managing our sessions.

7. Conclusion

Spring Session is a powerful tool for managing HTTP sessions. With our session storage simplified to a configuration class and a few Maven dependencies, we can now wire up multiple applications to the same Redis instance and share authentication information.

Full example code is on Github.