# `HttpSession` Integration Spring Session provides transparent integration with `HttpSession`. This means that developers can switch the `HttpSession` implementation out with an implementation that is backed by Spring Session. ## [](#httpsession-why)Why Spring Session and `HttpSession`? We have already mentioned that Spring Session provides transparent integration with `HttpSession`, but what benefits do we get out of this? * **Clustered Sessions**: Spring Session makes it trivial to support [clustered sessions](#httpsession-redis) without being tied to an application container specific solution. * **RESTful APIs**: Spring Session lets providing session IDs in headers work with [RESTful APIs](#httpsession-rest) ## [](#httpsession-redis)`HttpSession` with Redis Using Spring Session with `HttpSession` is enabled by adding a Servlet Filter before anything that uses the `HttpSession`. You can choose from enabling this by using either: * [Java-based Configuration](#httpsession-redis-jc) * [XML-based Configuration](#httpsession-redis-xml) ### [](#httpsession-redis-jc)Redis Java-based Configuration This section describes how to use Redis to back `HttpSession` by using Java based configuration. | |The [ HttpSession Sample](samples.html#samples) provides a working sample of how to integrate Spring Session and `HttpSession` by using Java configuration.
You can read the basic steps for integration in the next few sections, but we encourage you to follow along with the detailed HttpSession Guide when integrating with your own application.| |---|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| #### [](#httpsession-spring-configuration)Spring Java Configuration After adding the required dependencies, we can create our Spring configuration. The Spring configuration is responsible for creating a servlet filter that replaces the `HttpSession` implementation with an implementation backed by Spring Session. To do so, add the following Spring Configuration: ``` @EnableRedisHttpSession (1) public class Config { @Bean public LettuceConnectionFactory connectionFactory() { return new LettuceConnectionFactory(); (2) } } ``` |**1**| The `@EnableRedisHttpSession` annotation creates a Spring Bean with the name of `springSessionRepositoryFilter` that implements `Filter`.
The filter is in charge of replacing the `HttpSession` implementation to be backed by Spring Session.
In this instance, Spring Session is backed by Redis. | |-----|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| |**2**|We create a `RedisConnectionFactory` that connects Spring Session to the Redis Server.
We configure the connection to connect to localhost on the default port (6379).
For more information on configuring Spring Data Redis, see the [reference documentation](https://docs.spring.io/spring-data/data-redis/docs/2.6.2/reference/html/).| #### [](#_java_servlet_container_initialization)Java Servlet Container Initialization Our [Spring Configuration](#httpsession-spring-configuration) created a Spring Bean named `springSessionRepositoryFilter` that implements `Filter`. The `springSessionRepositoryFilter` bean is responsible for replacing the `HttpSession` with a custom implementation that is backed by Spring Session. In order for our `Filter` to do its magic, Spring needs to load our `Config` class. Last, we need to ensure that our Servlet Container (that is, Tomcat) uses our `springSessionRepositoryFilter` for every request. Fortunately, Spring Session provides a utility class named `AbstractHttpSessionApplicationInitializer` to make both of these steps easy. The following shows an example: src/main/java/sample/Initializer.java ``` public class Initializer extends AbstractHttpSessionApplicationInitializer { (1) public Initializer() { super(Config.class); (2) } } ``` | |The name of our class (`Initializer`) does not matter. What is important is that we extend `AbstractHttpSessionApplicationInitializer`.| |---|---------------------------------------------------------------------------------------------------------------------------------------| |**1**|The first step is to extend `AbstractHttpSessionApplicationInitializer`.
Doing so ensures that the Spring Bean by the name of `springSessionRepositoryFilter` is registered with our Servlet Container for every request.| |-----|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| |**2**| `AbstractHttpSessionApplicationInitializer` also provides a mechanism to ensure Spring loads our `Config`. | ### [](#httpsession-redis-xml)Redis XML-based Configuration This section describes how to use Redis to back `HttpSession` by using XML based configuration. | |The [ HttpSession XML Sample](samples.html#samples) provides a working sample of how to integrate Spring Session and `HttpSession` using XML configuration.
You can read the basic steps for integration in the next few sections, but we encourage you to follow along with the detailed HttpSession XML Guide when integrating with your own application.| |---|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| #### [](#httpsession-xml-spring-configuration)Spring XML Configuration After adding the required dependencies, we can create our Spring configuration. The Spring configuration is responsible for creating a servlet filter that replaces the `HttpSession` implementation with an implementation backed by Spring Session. To do so, add the following Spring Configuration: src/main/webapp/WEB-INF/spring/session.xml ``` (1) (2) ``` |**1**|We use the combination of `` and `RedisHttpSessionConfiguration` because Spring Session does not yet provide XML Namespace support (see [gh-104](https://github.com/spring-projects/spring-session/issues/104)).
This creates a Spring Bean with the name of `springSessionRepositoryFilter` that implements `Filter`.
The filter is in charge of replacing the `HttpSession` implementation to be backed by Spring Session.
In this instance, Spring Session is backed by Redis.| |-----|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| |**2**| We create a `RedisConnectionFactory` that connects Spring Session to the Redis Server.
We configure the connection to connect to localhost on the default port (6379)
For more information on configuring Spring Data Redis, see the [reference documentation](https://docs.spring.io/spring-data/data-redis/docs/2.6.2/reference/html/). | #### [](#_xml_servlet_container_initialization)XML Servlet Container Initialization Our [Spring Configuration](#httpsession-xml-spring-configuration) created a Spring Bean named `springSessionRepositoryFilter` that implements `Filter`. The `springSessionRepositoryFilter` bean is responsible for replacing the `HttpSession` with a custom implementation that is backed by Spring Session. In order for our `Filter` to do its magic, we need to instruct Spring to load our `session.xml` configuration. We can do so with the following configuration: src/main/webapp/WEB-INF/web.xml ``` contextConfigLocation /WEB-INF/spring/session.xml org.springframework.web.context.ContextLoaderListener ``` The [`ContextLoaderListener`](https://docs.spring.io/spring/docs/5.3.16/spring-framework-reference/core.html#context-create) reads the contextConfigLocation and picks up our session.xml configuration. Last, we need to ensure that our Servlet Container (that is, Tomcat) uses our `springSessionRepositoryFilter` for every request. The following snippet performs this last step for us: src/main/webapp/WEB-INF/web.xml ``` springSessionRepositoryFilter org.springframework.web.filter.DelegatingFilterProxy springSessionRepositoryFilter /* REQUEST ERROR ``` The [`DelegatingFilterProxy`](https://docs.spring.io/spring-framework/docs/5.3.16/javadoc-api/org/springframework/web/filter/DelegatingFilterProxy.html) looks up a Bean by the name of `springSessionRepositoryFilter` and cast it to a `Filter`. For every request that `DelegatingFilterProxy` is invoked, the `springSessionRepositoryFilter` is invoked. ### [](#httpsession-mongo)HttpSession with Mongo Using Spring Session with `HttpSession` is enabled by adding a Servlet Filter before anything that uses the `HttpSession`. This section describes how to use Mongo to back `HttpSession` using Java based configuration. | |The [HttpSession Mongo Sample](#samples) provides a working sample on how to integrate Spring Session and `HttpSession` using Java configuration.
You can read the basic steps for integration below, but you are encouraged to follow along with the detailed HttpSession Guide when integrating with your own application.| |---|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| All you have to do is to add the following Spring Configuration: ``` @EnableMongoHttpSession (1) public class HttpSessionConfig { @Bean public JdkMongoSessionConverter jdkMongoSessionConverter() { return new JdkMongoSessionConverter(Duration.ofMinutes(30)); (2) } } ``` |**1**|The `@EnableMongoHttpSession` annotation creates a Spring Bean with the name of `springSessionRepositoryFilter` that implements Filter.
This filter is what replaces the default `HttpSession` with the MongoDB-backed bean.| |-----|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| |**2**| Configures the session timeout to 30 minutes. | #### [](#_session_serialization_mechanisms)Session serialization mechanisms To be able to persist session objects in MongoDB we need to provide the serialization/deserialization mechanism. By default, Spring Session MongoDB will use `JdkMongoSessionConverter`. However, you may switch to `JacksonMongoSessionConverter` by merely adding the following code to your Boot app: ``` @Bean JacksonMongoSessionConverter mongoSessionConverter() { return new JacksonMongoSessionConverter(); } ``` ##### [](#_jacksonmongosessionconverter)JacksonMongoSessionConverter This mechanism uses Jackson to serialize session objects to/from JSON. By creating the following bean: ``` @Bean JacksonMongoSessionConverter mongoSessionConverter() { return new JacksonMongoSessionConverter(); } ``` …​you are able to switch from the default (JDK-based serialization) to using Jackson. | |If you are integrating with Spring Security (by storing your sessions in MongoDB), this configuration will
register the proper whitelisted components so Spring Security works properly.| |---|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| If you would like to provide custom Jackson modules you can do it by explicitly registering modules as shown below: ``` @Configuration @EnableMongoHttpSession static class Config extends BaseConfig { @Bean AbstractMongoSessionConverter mongoSessionConverter() { return new JacksonMongoSessionConverter(Collections.singletonList(new GeoModule())); } } ``` ##### [](#_jdkmongosessionconverter)JdkMongoSessionConverter `JdkMongoSessionConverter` uses standard Java serialization to persist session attributes map to MongoDB in a binary form. However, standard session elements like id, access time, etc are still written as a plain Mongo objects and can be read and queried without additional effort.`JdkMongoSessionConverter` is used if no explicit `AbstractMongoSessionConverter` Bean has been defined. There is also a constructor taking `Serializer` and `Deserializer` objects, allowing you to pass custom implementations, which is especially important when you want to use non-default classloader. ## [](#httpsession-jdbc)`HttpSession` with JDBC You can use Spring Session with `HttpSession` by adding a servlet filter before anything that uses the `HttpSession`. You can choose to do in any of the following ways: * [Java-based Configuration](#httpsession-jdbc-jc) * [XML-based Configuration](#httpsession-jdbc-xml) * [Spring Boot-based Configuration](#httpsession-jdbc-boot) ### [](#httpsession-jdbc-jc)JDBC Java-based Configuration This section describes how to use a relational database to back `HttpSession` when you use Java-based configuration. | |The [ HttpSession JDBC Sample](samples.html#samples) provides a working sample of how to integrate Spring Session and `HttpSession` by using Java configuration.
You can read the basic steps for integration in the next few sections, but we encouraged you to follow along with the detailed HttpSession JDBC Guide when integrating with your own application.| |---|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| #### [](#httpsession-jdbc-spring-configuration)Spring Java Configuration After adding the required dependencies, we can create our Spring configuration. The Spring configuration is responsible for creating a Servlet Filter that replaces the `HttpSession` implementation with an implementation backed by Spring Session. To do so, add the following Spring Configuration: ``` @EnableJdbcHttpSession (1) public class Config { @Bean public EmbeddedDatabase dataSource() { return new EmbeddedDatabaseBuilder() (2) .setType(EmbeddedDatabaseType.H2).addScript("org/springframework/session/jdbc/schema-h2.sql").build(); } @Bean public PlatformTransactionManager transactionManager(DataSource dataSource) { return new DataSourceTransactionManager(dataSource); (3) } } ``` |**1**|The `@EnableJdbcHttpSession` annotation creates a Spring Bean with the name of `springSessionRepositoryFilter`.
That bean implements `Filter`.
The filter is in charge of replacing the `HttpSession` implementation to be backed by Spring Session.
In this instance, Spring Session is backed by a relational database.| |-----|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| |**2**| We create a `dataSource` that connects Spring Session to an embedded instance of an H2 database.
We configure the H2 database to create database tables by using the SQL script that is included in Spring Session. | |**3**| We create a `transactionManager` that manages transactions for previously configured `dataSource`. | For additional information on how to configure data access related concerns, see the [Spring Framework Reference Documentation](https://docs.spring.io/spring/docs/5.3.16/spring-framework-reference/data-access.html). #### [](#_java_servlet_container_initialization_2)Java Servlet Container Initialization Our [Spring Configuration](#httpsession-jdbc-spring-configuration) created a Spring bean named `springSessionRepositoryFilter` that implements `Filter`. The `springSessionRepositoryFilter` bean is responsible for replacing the `HttpSession` with a custom implementation that is backed by Spring Session. In order for our `Filter` to do its magic, Spring needs to load our `Config` class. Last, we need to ensure that our Servlet Container (that is, Tomcat) uses our `springSessionRepositoryFilter` for every request. Fortunately, Spring Session provides a utility class named `AbstractHttpSessionApplicationInitializer` to make both of these steps easy. The following example shows how to do so: src/main/java/sample/Initializer.java ``` public class Initializer extends AbstractHttpSessionApplicationInitializer { (1) public Initializer() { super(Config.class); (2) } } ``` | |The name of our class (Initializer) does not matter.
What is important is that we extend `AbstractHttpSessionApplicationInitializer`.| |---|-----------------------------------------------------------------------------------------------------------------------------------------| |**1**|The first step is to extend `AbstractHttpSessionApplicationInitializer`.
Doing so ensures that the Spring bean named `springSessionRepositoryFilter` is registered with our Servlet Container for every request.| |-----|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| |**2**| `AbstractHttpSessionApplicationInitializer` also provides a mechanism to ensure Spring loads our `Config`. | #### [](#_multiple_datasources)Multiple DataSources Spring Session provides the `@SpringSessionDataSource` qualifier, allowing you to explicitly declare which `DataSource` bean should be injected in `JdbcIndexedSessionRepository`. This is particularly useful in scenarios with multiple `DataSource` beans present in the application context. The following example shows how to do so: Config.java ``` @EnableJdbcHttpSession public class Config { @Bean @SpringSessionDataSource (1) public EmbeddedDatabase firstDataSource() { return new EmbeddedDatabaseBuilder() .setType(EmbeddedDatabaseType.H2).addScript("org/springframework/session/jdbc/schema-h2.sql").build(); } @Bean public HikariDataSource secondDataSource() { // ... } } ``` |**1**|This qualifier declares that firstDataSource is to be used by Spring Session.| |-----|-----------------------------------------------------------------------------| ### [](#httpsession-jdbc-xml)JDBC XML-based Configuration This section describes how to use a relational database to back `HttpSession` when you use XML based configuration. | |The [ HttpSession JDBC XML Sample](samples.html#samples) provides a working sample of how to integrate Spring Session and `HttpSession` by using XML configuration.
You can read the basic steps for integration in the next few sections, but we encourage you to follow along with the detailed HttpSession JDBC XML Guide when integrating with your own application.| |---|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| #### [](#httpsession-jdbc-xml-spring-configuration)Spring XML Configuration After adding the required dependencies, we can create our Spring configuration. The Spring configuration is responsible for creating a servlet filter that replaces the `HttpSession` implementation with an implementation backed by Spring Session. The following listing shows how to add the following Spring Configuration: src/main/webapp/WEB-INF/spring/session.xml ``` (1) (2) (3) ``` |**1**|We use the combination of `` and `JdbcHttpSessionConfiguration` because Spring Session does not yet provide XML Namespace support (see [gh-104](https://github.com/spring-projects/spring-session/issues/104)).
This creates a Spring bean with the name of `springSessionRepositoryFilter`.
That bean implements `Filter`.
The filter is in charge of replacing the `HttpSession` implementation to be backed by Spring Session.
In this instance, Spring Session is backed by a relational database.| |-----|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| |**2**| We create a `dataSource` that connects Spring Session to an embedded instance of an H2 database.
We configure the H2 database to create database tables by using the SQL script that is included in Spring Session. | |**3**| We create a `transactionManager` that manages transactions for previously configured `dataSource`. | For additional information on how to configure data access-related concerns, see the [Spring Framework Reference Documentation](https://docs.spring.io/spring/docs/5.3.16/spring-framework-reference/data-access.html). #### [](#_xml_servlet_container_initialization_2)XML Servlet Container Initialization Our [Spring Configuration](#httpsession-jdbc-xml-spring-configuration) created a Spring bean named `springSessionRepositoryFilter` that implements `Filter`. The `springSessionRepositoryFilter` bean is responsible for replacing the `HttpSession` with a custom implementation that is backed by Spring Session. In order for our `Filter` to do its magic, we need to instruct Spring to load our `session.xml` configuration. We do so with the following configuration: src/main/webapp/WEB-INF/web.xml ``` contextConfigLocation /WEB-INF/spring/session.xml org.springframework.web.context.ContextLoaderListener ``` The [`ContextLoaderListener`](https://docs.spring.io/spring/docs/5.3.16/spring-framework-reference/core.html#context-create) reads the `contextConfigLocation` and picks up our session.xml configuration. Last, we need to ensure that our Servlet Container (that is, Tomcat) uses our `springSessionRepositoryFilter` for every request. The following snippet performs this last step for us: src/main/webapp/WEB-INF/web.xml ``` springSessionRepositoryFilter org.springframework.web.filter.DelegatingFilterProxy springSessionRepositoryFilter /* REQUEST ERROR ``` The [`DelegatingFilterProxy`](https://docs.spring.io/spring-framework/docs/5.3.16/javadoc-api/org/springframework/web/filter/DelegatingFilterProxy.html) looks up a bean named `springSessionRepositoryFilter` and casts it to a `Filter`. For every request on which `DelegatingFilterProxy` is invoked, the `springSessionRepositoryFilter` is invoked. ### [](#httpsession-jdbc-boot)JDBC Spring Boot-based Configuration This section describes how to use a relational database to back `HttpSession` when you use Spring Boot. | |The [ HttpSession JDBC Spring Boot Sample](samples.html#samples) provides a working sample of how to integrate Spring Session and `HttpSession` by using Spring Boot.
You can read the basic steps for integration in the next few sections, but we encourage you to follow along with the detailed HttpSession JDBC Spring Boot Guide when integrating with your own application.| |---|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| #### [](#httpsession-jdbc-boot-spring-configuration)Spring Boot Configuration After adding the required dependencies, we can create our Spring Boot configuration. Thanks to first-class auto configuration support, setting up Spring Session backed by a relational database is as simple as adding a single configuration property to your `application.properties`. The following listing shows how to do so: src/main/resources/application.properties ``` spring.session.store-type=jdbc # Session store type. ``` If a single Spring Session module is present on the classpath, Spring Boot uses that store implementation automatically. If you have more than one implementation, you must choose the StoreType that you wish to use to store the sessions, as shows above. Under the hood, Spring Boot applies configuration that is equivalent to manually adding the `@EnableJdbcHttpSession` annotation. This creates a Spring bean with the name of `springSessionRepositoryFilter`. That bean implements `Filter`. The filter is in charge of replacing the `HttpSession` implementation to be backed by Spring Session. You can further customize by using `application.properties`. The following listing shows how to do so: src/main/resources/application.properties ``` server.servlet.session.timeout= # Session timeout. If a duration suffix is not specified, seconds are used. spring.session.jdbc.initialize-schema=embedded # Database schema initialization mode. spring.session.jdbc.schema=classpath:org/springframework/session/jdbc/[email protected]@[email protected]@.sql # Path to the SQL file to use to initialize the database schema. spring.session.jdbc.table-name=SPRING_SESSION # Name of the database table used to store sessions. ``` For more information, see the [Spring Session](https://docs.spring.io/spring-boot/docs/2.5.6/reference/htmlsingle/#boot-features-session) portion of the Spring Boot documentation. #### [](#httpsession-jdbc-boot-configuration)Configuring the `DataSource` Spring Boot automatically creates a `DataSource` that connects Spring Session to an embedded instance of an H2 database. In a production environment, you need to update your configuration to point to your relational database. For example, you can include the following in your application.properties: src/main/resources/application.properties ``` spring.datasource.url= # JDBC URL of the database. spring.datasource.username= # Login username of the database. spring.datasource.password= # Login password of the database. ``` For more information, see the [Configure a DataSource](https://docs.spring.io/spring-boot/docs/2.5.6/reference/htmlsingle/#boot-features-configure-datasource) portion of the Spring Boot documentation. #### [](#httpsession-jdbc-boot-servlet-configuration)Servlet Container Initialization Our [Spring Boot Configuration](#httpsession-jdbc-boot-spring-configuration) created a Spring bean named `springSessionRepositoryFilter` that implements `Filter`. The `springSessionRepositoryFilter` bean is responsible for replacing the `HttpSession` with a custom implementation that is backed by Spring Session. In order for our `Filter` to do its magic, Spring needs to load our `Config` class. Last, we need to ensure that our Servlet Container (that is, Tomcat) uses our `springSessionRepositoryFilter` for every request. Fortunately, Spring Boot takes care of both of these steps for us. ## [](#httpsession-hazelcast)HttpSession with Hazelcast Using Spring Session with `HttpSession` is enabled by adding a Servlet Filter before anything that uses the `HttpSession`. This section describes how to use Hazelcast to back `HttpSession` by using Java-based configuration. | |The [ Hazelcast Spring Sample](samples.html#samples) provides a working sample of how to integrate Spring Session and `HttpSession` by using Java configuration.
You can read the basic steps for integration in the next few sections, but we encourage you to follow along with the detailed Hazelcast Spring Guide when integrating with your own application.| |---|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| ### [](#security-spring-configuration)Spring Configuration After adding the required dependencies, we can create our Spring configuration. The Spring configuration is responsible for creating a servlet filter that replaces the `HttpSession` implementation with an implementation backed by Spring Session. To do so, add the following Spring Configuration: ``` @EnableHazelcastHttpSession (1) @Configuration public class HazelcastHttpSessionConfig { @Bean public HazelcastInstance hazelcastInstance() { Config config = new Config(); MapAttributeConfig attributeConfig = new MapAttributeConfig() .setName(HazelcastIndexedSessionRepository.PRINCIPAL_NAME_ATTRIBUTE) .setExtractor(PrincipalNameExtractor.class.getName()); config.getMapConfig(HazelcastIndexedSessionRepository.DEFAULT_SESSION_MAP_NAME) (2) .addMapAttributeConfig(attributeConfig).addMapIndexConfig( new MapIndexConfig(HazelcastIndexedSessionRepository.PRINCIPAL_NAME_ATTRIBUTE, false)); SerializerConfig serializerConfig = new SerializerConfig(); serializerConfig.setImplementation(new HazelcastSessionSerializer()).setTypeClass(MapSession.class); config.getSerializationConfig().addSerializerConfig(serializerConfig); (3) return Hazelcast.newHazelcastInstance(config); (4) } } ``` |**1**| The `@EnableHazelcastHttpSession` annotation creates a Spring bean named `springSessionRepositoryFilter` that implements `Filter`.
The filter is in charge of replacing the `HttpSession` implementation to be backed by Spring Session.
In this instance, Spring Session is backed by Hazelcast. | |-----|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| |**2**| In order to support retrieval of sessions by principal name index, an appropriate `ValueExtractor` needs to be registered.
Spring Session provides `PrincipalNameExtractor` for this purpose. | |**3**| In order to serialize `MapSession` objects efficiently, `HazelcastSessionSerializer` needs to be registered. If this
is not set, Hazelcast will serialize sessions using native Java serialization. | |**4**|We create a `HazelcastInstance` that connects Spring Session to Hazelcast.
By default, the application starts and connects to an embedded instance of Hazelcast.
For more information on configuring Hazelcast, see the [reference documentation](https://docs.hazelcast.org/docs/3.12.12/manual/html-single/index.html#hazelcast-configuration).| | |If `HazelcastSessionSerializer` is preferred, it needs to be configured for all Hazelcast cluster members before they start.
In a Hazelcast cluster, all members should use the same serialization method for sessions. Also, if Hazelcast Client/Server topology
is used, then both members and clients must use the same serialization method. The serializer can be registered via `ClientConfig`with the same `SerializerConfiguration` of members.| |---|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| ### [](#_servlet_container_initialization)Servlet Container Initialization Our [Spring Configuration](guides/java-security.html#security-spring-configuration) created a Spring bean named `springSessionRepositoryFilter` that implements `Filter`. The `springSessionRepositoryFilter` bean is responsible for replacing the `HttpSession` with a custom implementation that is backed by Spring Session. In order for our `Filter` to do its magic, Spring needs to load our `SessionConfig` class. Since our application is already loading Spring configuration by using our `SecurityInitializer` class, we can add our `SessionConfig` class to it. The following listing shows how to do so: src/main/java/sample/SecurityInitializer.java ``` public class SecurityInitializer extends AbstractSecurityWebApplicationInitializer { public SecurityInitializer() { super(SecurityConfig.class, SessionConfig.class); } } ``` Last, we need to ensure that our Servlet Container (that is, Tomcat) uses our `springSessionRepositoryFilter` for every request. It is extremely important that Spring Session’s `springSessionRepositoryFilter` is invoked before Spring Security’s `springSecurityFilterChain`. Doing so ensures that the `HttpSession` that Spring Security uses is backed by Spring Session. Fortunately, Spring Session provides a utility class named `AbstractHttpSessionApplicationInitializer` that makes this doing so easy. The following example shows how to do so: src/main/java/sample/Initializer.java ``` public class Initializer extends AbstractHttpSessionApplicationInitializer { } ``` | |The name of our class (`Initializer`) does not matter. What is important is that we extend `AbstractHttpSessionApplicationInitializer`.| |---|---------------------------------------------------------------------------------------------------------------------------------------| By extending `AbstractHttpSessionApplicationInitializer`, we ensure that the Spring Bean named `springSessionRepositoryFilter` is registered with our servlet container for every request before Spring Security’s `springSecurityFilterChain`. ## [](#httpsession-how)How `HttpSession` Integration Works Fortunately, both `HttpSession` and `HttpServletRequest` (the API for obtaining an `HttpSession`) are both interfaces. This means that we can provide our own implementations for each of these APIs. | |This section describes how Spring Session provides transparent integration with `HttpSession`. We offer this content so that you can understand what is happening under the covers. This functionality is already integrated and you do NOT need to implement this logic yourself.| |---|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| First, we create a custom `HttpServletRequest` that returns a custom implementation of `HttpSession`. It looks something like the following: ``` public class SessionRepositoryRequestWrapper extends HttpServletRequestWrapper { public SessionRepositoryRequestWrapper(HttpServletRequest original) { super(original); } public HttpSession getSession() { return getSession(true); } public HttpSession getSession(boolean createNew) { // create an HttpSession implementation from Spring Session } // ... other methods delegate to the original HttpServletRequest ... } ``` Any method that returns an `HttpSession` is overridden. All other methods are implemented by `HttpServletRequestWrapper` and delegate to the original `HttpServletRequest` implementation. We replace the `HttpServletRequest` implementation by using a servlet `Filter` called `SessionRepositoryFilter`. The following pseudocode shows how it works: ``` public class SessionRepositoryFilter implements Filter { public doFilter(ServletRequest request, ServletResponse response, FilterChain chain) { HttpServletRequest httpRequest = (HttpServletRequest) request; SessionRepositoryRequestWrapper customRequest = new SessionRepositoryRequestWrapper(httpRequest); chain.doFilter(customRequest, response, chain); } // ... } ``` By passing a custom `HttpServletRequest` implementation into the `FilterChain`, we ensure that anything invoked after our `Filter` uses the custom `HttpSession` implementation. This highlights why it is important that Spring Session’s `SessionRepositoryFilter` be placed before anything that interacts with the `HttpSession`. ## [](#httpsession-rest)`HttpSession` and RESTful APIs Spring Session can work with RESTful APIs by letting the session be provided in a header. | |The [ REST Sample](samples.html#samples) provides a working sample of how to use Spring Session in a REST application to support authenticating with a header.
You can follow the basic steps for integration described in the next few sections, but we encourage you to follow along with the detailed REST Guide when integrating with your own application.| |---|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| ### [](#rest-spring-configuration)Spring Configuration After adding the required dependencies, we can create our Spring configuration. The Spring configuration is responsible for creating a servlet filter that replaces the `HttpSession` implementation with an implementation backed by Spring Session. To do so, add the following Spring Configuration: ``` @Configuration @EnableRedisHttpSession (1) public class HttpSessionConfig { @Bean public LettuceConnectionFactory connectionFactory() { return new LettuceConnectionFactory(); (2) } @Bean public HttpSessionIdResolver httpSessionIdResolver() { return HeaderHttpSessionIdResolver.xAuthToken(); (3) } } ``` |**1**| The `@EnableRedisHttpSession` annotation creates a Spring bean named `springSessionRepositoryFilter` that implements `Filter`.
The filter is in charge of replacing the `HttpSession` implementation to be backed by Spring Session.
In this instance, Spring Session is backed by Redis. | |-----|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| |**2**|We create a `RedisConnectionFactory` that connects Spring Session to the Redis Server.
We configure the connection to connect to localhost on the default port (6379).
For more information on configuring Spring Data Redis, see the [reference documentation](https://docs.spring.io/spring-data/data-redis/docs/2.6.2/reference/html/).| |**3**| We customize Spring Session’s HttpSession integration to use HTTP headers to convey the current session information instead of cookies. | ### [](#_servlet_container_initialization_2)Servlet Container Initialization Our [Spring Configuration](#rest-spring-configuration) created a Spring Bean named `springSessionRepositoryFilter` that implements `Filter`. The `springSessionRepositoryFilter` bean is responsible for replacing the `HttpSession` with a custom implementation that is backed by Spring Session. In order for our `Filter` to do its magic, Spring needs to load our `Config` class. We provide the configuration in our Spring `MvcInitializer`, as the following example shows: src/main/java/sample/mvc/MvcInitializer.java ``` @Override protected Class[] getRootConfigClasses() { return new Class[] { SecurityConfig.class, HttpSessionConfig.class }; } ``` Last, we need to ensure that our Servlet Container (that is, Tomcat) uses our `springSessionRepositoryFilter` for every request. Fortunately, Spring Session provides a utility class named `AbstractHttpSessionApplicationInitializer` that makes doing so easy. To do so, extend the class with the default constructor, as the following example shows: src/main/java/sample/Initializer.java ``` public class Initializer extends AbstractHttpSessionApplicationInitializer { } ``` | |The name of our class (`Initializer`) does not matter. What is important is that we extend `AbstractHttpSessionApplicationInitializer`.| |---|---------------------------------------------------------------------------------------------------------------------------------------| ## [](#httpsession-httpsessionlistener)Using `HttpSessionListener` Spring Session supports `HttpSessionListener` by translating `SessionDestroyedEvent` and `SessionCreatedEvent` into `HttpSessionEvent` by declaring `SessionEventHttpSessionListenerAdapter`. To use this support, you need to: * Ensure your `SessionRepository` implementation supports and is configured to fire `SessionDestroyedEvent` and `SessionCreatedEvent`. * Configure `SessionEventHttpSessionListenerAdapter` as a Spring bean. * Inject every `HttpSessionListener` into the `SessionEventHttpSessionListenerAdapter` If you use the configuration support documented in [`HttpSession` with Redis](#httpsession-redis), all you need to do is register every `HttpSessionListener` as a bean. For example, assume you want to support Spring Security’s concurrency control and need to use `HttpSessionEventPublisher`. In that case, you can add `HttpSessionEventPublisher` as a bean. In Java configuration, this might look like the following: ``` @Configuration @EnableRedisHttpSession public class RedisHttpSessionConfig { @Bean public HttpSessionEventPublisher httpSessionEventPublisher() { return new HttpSessionEventPublisher(); } // ... } ``` In XML configuration, this might look like the following: ``` ```