= Spring Session
Rob Winch; Vedran Pavić; Jay Bryant; Eleftheria Stein-Kousathana
:doctype: book
:indexdoc-tests: {docs-test-dir}docs/IndexDocTests.java
:websocketdoc-test-dir: {docs-test-dir}docs/websocket/
:toc: left

[[abstract]]
Spring Session provides an API and implementations for managing a user's session information.

[[introduction]]
== Introduction

Spring Session provides an API and implementations for managing a user's session information while also making it trivial to support clustered sessions without being tied to an application container-specific solution.
It also provides transparent integration with:

* <<httpsession,HttpSession>>: Allows replacing the `HttpSession` in an application container-neutral way, with support for providing session IDs in headers to work with RESTful APIs.
* <<websocket,WebSocket>>: Provides the ability to keep the `HttpSession` alive when receiving WebSocket messages
* <<websession,WebSession>>: Allows replacing the Spring WebFlux's `WebSession` in an application container-neutral way.

== What's New in 2.0

The following list highlights what is new in Spring Session 2.0:

* Upgraded to Java 8 and Spring Framework 5 as baseline
* https://github.com/spring-projects/spring-session/issues/683[Added support for managing Spring WebFlux's `WebSession`] with https://github.com/spring-projects/spring-session/issues/816[Redis `ReactiveSessionRepository`]
* https://github.com/spring-projects/spring-session/issues/768[Extracted `SessionRepository` implementations to separate modules]
* Improved https://github.com/spring-projects/spring-session/issues/682[`Session`] and https://github.com/spring-projects/spring-session/issues/809[`SessionRepository`] APIs
* Improved and harmonized configuration support for all supported session stores
* https://github.com/spring-projects/spring-session/pull/713[Added support for configuring default `CookieSerializer` using `SessionCookieConfig`]
* Lots of performance improvements and bug fixes

You can find a complete list of what is new by referring to the changelogs of

* https://github.com/spring-projects/spring-session/milestone/17?closed=1[2.0.0.M1]
* https://github.com/spring-projects/spring-session/milestone/22?closed=1[2.0.0.M2]
* https://github.com/spring-projects/spring-session/milestone/23?closed=1[2.0.0.M3]
* https://github.com/spring-projects/spring-session/milestone/24?closed=1[2.0.0.M4]
* https://github.com/spring-projects/spring-session/milestone/25?closed=1[2.0.0.M5]
* https://github.com/spring-projects/spring-session/milestone/26?closed=1[2.0.0.RC1]
* https://github.com/spring-projects/spring-session/milestone/27?closed=1[2.0.0.RC2]
* https://github.com/spring-projects/spring-session/milestone/30?closed=1[2.0.0.RELEASE]

[[samples]]
== Samples and Guides (Start Here)

To get started with Spring Session, the best place to start is our Sample Applications.

.Sample Applications that use Spring Boot
|===
| Source | Description | Guide

| {gh-samples-url}spring-session-sample-boot-redis[HttpSession with Redis]
| Demonstrates how to use Spring Session to replace the `HttpSession` with Redis.
| link:guides/boot-redis.html[HttpSession with Redis Guide]

| {gh-samples-url}spring-session-sample-boot-jdbc[HttpSession with JDBC]
| Demonstrates how to use Spring Session to replace the `HttpSession` with a relational database store.
| link:guides/boot-jdbc.html[HttpSession with JDBC Guide]

| {gh-samples-url}spring-session-sample-boot-hazelcast[HttpSession with Hazelcast]
| Demonstrates how to use Spring Session to replace the `HttpSession` with Hazelcast.
|

| {gh-samples-url}spring-session-sample-boot-findbyusername[Find by Username]
| Demonstrates how to use Spring Session to find sessions by username.
| link:guides/boot-findbyusername.html[Find by Username Guide]

| {gh-samples-url}spring-session-sample-boot-websocket[WebSockets]
| Demonstrates how to use Spring Session with WebSockets.
| link:guides/boot-websocket.html[WebSockets Guide]

| {gh-samples-url}spring-session-sample-boot-webflux[WebFlux]
| Demonstrates how to use Spring Session to replace the Spring WebFlux's `WebSession` with Redis.
|

| {gh-samples-url}spring-session-sample-boot-webflux-custom-cookie[WebFlux with Custom Cookie]
| Demonstrates how to use Spring Session to customize the Session cookie in a WebFlux based application.
| link:guides/boot-webflux-custom-cookie.html[WebFlux with Custom Cookie Guide]

| {gh-samples-url}spring-session-sample-boot-redis-json[HttpSession with Redis JSON serialization]
| Demonstrates how to use Spring Session to replace the `HttpSession` with Redis using JSON serialization.
|

| {gh-samples-url}spring-session-sample-boot-redis-simple[HttpSession with simple Redis `SessionRepository`]
| Demonstrates how to use Spring Session to replace the `HttpSession` with Redis using `RedisSessionRepository`.
|

|===

.Sample Applications that use Spring Java-based configuration
|===
| Source | Description | Guide

| {gh-samples-url}spring-session-sample-javaconfig-redis[HttpSession with Redis]
| Demonstrates how to use Spring Session to replace the `HttpSession` with Redis.
| link:guides/java-redis.html[HttpSession with Redis Guide]

| {gh-samples-url}spring-session-sample-javaconfig-jdbc[HttpSession with JDBC]
| Demonstrates how to use Spring Session to replace the `HttpSession` with a relational database store.
| link:guides/java-jdbc.html[HttpSession with JDBC Guide]

| {gh-samples-url}spring-session-sample-javaconfig-hazelcast[HttpSession with Hazelcast]
| Demonstrates how to use Spring Session to replace the `HttpSession` with Hazelcast.
| link:guides/java-hazelcast.html[HttpSession with Hazelcast Guide]

| {gh-samples-url}spring-session-sample-javaconfig-custom-cookie[Custom Cookie]
| Demonstrates how to use Spring Session and customize the cookie.
| link:guides/java-custom-cookie.html[Custom Cookie Guide]

| {gh-samples-url}spring-session-sample-javaconfig-security[Spring Security]
| Demonstrates how to use Spring Session with an existing Spring Security application.
| link:guides/java-security.html[Spring Security Guide]

| {gh-samples-url}spring-session-sample-javaconfig-rest[REST]
| Demonstrates how to use Spring Session in a REST application to support authenticating with a header.
| link:guides/java-rest.html[REST Guide]

|===

.Sample Applications that use Spring XML-based configuration
|===
| Source | Description | Guide

| {gh-samples-url}spring-session-sample-xml-redis[HttpSession with Redis]
| Demonstrates how to use Spring Session to replace the `HttpSession` with a Redis store.
| link:guides/xml-redis.html[HttpSession with Redis Guide]

| {gh-samples-url}spring-session-sample-xml-jdbc[HttpSession with JDBC]
| Demonstrates how to use Spring Session to replace the `HttpSession` with a relational database store.
| link:guides/xml-jdbc.html[HttpSession with JDBC Guide]

|===

.Miscellaneous sample Applications
|===
| Source | Description | Guide

| {gh-samples-url}spring-session-sample-misc-hazelcast[Hazelcast]
| Demonstrates how to use Spring Session with Hazelcast in a Java EE application.
|

|===

[[modules]]
== Spring Session Modules

In Spring Session 1.x, all of the Spring Session's `SessionRepository` implementations were available within the `spring-session` artifact.
While convenient, this approach was not sustainable long-term as more features and `SessionRepository` implementations were added to the project.

Starting with Spring Session 2.0, the project has been split into Spring Session Core module and several other modules that carry `SessionRepository` implementations and functionality related to the specific data store.
Users of Spring Data should find this arrangement familiar, with Spring Session Core module taking a role equivalent to Spring Data Commons and providing core functionalities and APIs, with other modules containing data store specific implementations.
As part of this split, the Spring Session Data MongoDB and Spring Session Data GemFire modules were moved to separate repositories.
Now the situation with project's repositories/modules is as follows:

* https://github.com/spring-projects/spring-session[`spring-session` repository]
** Hosts the Spring Session Core, Spring Session Data Redis, Spring Session JDBC, and Spring Session Hazelcast modules
* https://github.com/spring-projects/spring-session-data-mongodb[`spring-session-data-mongodb` repository]
** Hosts the Spring Session Data MongoDB module
* https://github.com/spring-projects/spring-session-data-geode[`spring-session-data-geode` repository]
** Hosts the Spring Session Data Geode and Spring Session Data Geode modules

Finally, Spring Session now also provides a Maven BOM ("`bill of materials`") module in order to help users with version management concerns:

* https://github.com/spring-projects/spring-session-bom[`spring-session-bom` repository]
** Hosts the Spring Session BOM module

[[httpsession]]
== `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 <<httpsession-redis,clustered sessions>> without being tied to an application container specific solution.
* *RESTful APIs*: Spring Session lets providing session IDs in headers work with <<httpsession-rest,RESTful APIs>>

[[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:

* <<httpsession-redis-jc,Java-based Configuration>>
* <<httpsession-redis-xml,XML-based Configuration>>

[[httpsession-redis-jc]]
==== Redis Java-based Configuration

This section describes how to use Redis to back `HttpSession` by using Java based configuration.

NOTE: The <<samples, HttpSession Sample>> 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.

include::guides/java-redis.adoc[tags=config,leveloffset=+3]

[[httpsession-redis-xml]]
==== Redis XML-based Configuration

This section describes how to use Redis to back `HttpSession` by using XML based configuration.

NOTE: The <<samples, HttpSession XML Sample>> 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.

include::guides/xml-redis.adoc[tags=config,leveloffset=+3]

[[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:

* <<httpsession-jdbc-jc,Java-based Configuration>>
* <<httpsession-jdbc-xml,XML-based Configuration>>
* <<httpsession-jdbc-boot,Spring Boot-based Configuration>>

[[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.

NOTE: The <<samples, HttpSession JDBC Sample>> 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.

include::guides/java-jdbc.adoc[tags=config,leveloffset=+3]

[[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.

NOTE: The <<samples, HttpSession JDBC XML Sample>> 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.

include::guides/xml-jdbc.adoc[tags=config,leveloffset=+3]

[[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.

NOTE: The <<samples, HttpSession JDBC Spring Boot Sample>> 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.

include::guides/boot-jdbc.adoc[tags=config,leveloffset=+3]

[[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.

NOTE: The <<samples, Hazelcast Spring Sample>> 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.

include::guides/java-hazelcast.adoc[tags=config,leveloffset=+2]

[[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.

NOTE: 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:

====
[source, java]
----
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:

====
[source, java]
----
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.

NOTE: The <<samples, REST Sample>> 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.

include::guides/java-rest.adoc[tags=config,leveloffset=+2]

[[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-redis,`HttpSession` with 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:

====
[source,java,indent=0]
----
include::{docs-test-dir}docs/http/RedisHttpSessionConfig.java[tags=config]
----
====

In XML configuration, this might look like the following:

====
[source,xml,indent=0]
----
include::{docs-test-resources-dir}docs/http/HttpSessionListenerXmlTests-context.xml[tags=config]
----
====

[[websocket]]
== WebSocket Integration

Spring Session provides transparent integration with Spring's WebSocket support.

include::guides/boot-websocket.adoc[tags=disclaimer,leveloffset=+1]

[[websocket-why]]
=== Why Spring Session and WebSockets?

So why do we need Spring Session when we use WebSockets?

Consider an email application that does much of its work through HTTP requests.
However, there is also a chat application embedded within it that works over WebSocket APIs.
If a user is actively chatting with someone, we should not timeout the `HttpSession`, since this would be a pretty poor user experience.
However, this is exactly what https://java.net/jira/browse/WEBSOCKET_SPEC-175[JSR-356] does.

Another issue is that, according to JSR-356, if the `HttpSession` times out, any WebSocket that was created with that `HttpSession` and an authenticated user should be forcibly closed.
This means that, if we are actively chatting in our application and are not using the HttpSession, we also do disconnect from our conversation.

[[websocket-usage]]
=== WebSocket Usage

The <<samples, WebSocket Sample>> provides a working sample of how to integrate Spring Session with WebSockets.
You can follow the basic steps for integration described in the next few headings, but we encourage you to follow along with the detailed WebSocket Guide when integrating with your own application.

[[websocket-httpsession]]
==== `HttpSession` Integration

Before using WebSocket integration, you should be sure that you have <<httpsession>> working first.

include::guides/boot-websocket.adoc[tags=config,leveloffset=+2]

[[websession]]
== WebSession Integration

Spring Session provides transparent integration with Spring WebFlux's `WebSession`.
This means that you can switch the `WebSession` implementation out with an implementation that is backed by Spring Session.

[[websession-why]]
=== Why Spring Session and WebSession?

We have already mentioned that Spring Session provides transparent integration with Spring WebFlux's `WebSession`, but what benefits do we get out of this?
As with `HttpSession`, Spring Session makes it trivial to support <<websession-redis,clustered sessions>> without being tied to an application container specific solution.

[[websession-redis]]
=== WebSession with Redis

Using Spring Session with `WebSession` is enabled by registering a `WebSessionManager` implementation backed by Spring Session's `ReactiveSessionRepository`.
The Spring configuration is responsible for creating a `WebSessionManager` that replaces the `WebSession` implementation with an implementation backed by Spring Session.
To do so, add the following Spring Configuration:

====
[source, java]
----
@EnableRedisWebSession // <1>
public class SessionConfiguration {

	@Bean
	public LettuceConnectionFactory redisConnectionFactory() {
		return new LettuceConnectionFactory(); // <2>
	}

}
----

<1> The `@EnableRedisWebSession` annotation creates a Spring bean with the name of `webSessionManager`. That bean implements the `WebSessionManager`.
This is what is in charge of replacing the `WebSession` 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 https://docs.spring.io/spring-data/data-redis/docs/{spring-data-redis-version}/reference/html/[reference documentation].
====

[[websession-how]]
=== How WebSession Integration Works

It is considerably easier for Spring Session to integrate with Spring WebFlux and its `WebSession`, compared to Servlet API and its `HttpSession`.
Spring WebFlux provides the `WebSessionStore` API, which presents a strategy for persisting `WebSession`.

NOTE: This section describes how Spring Session provides transparent integration with `WebSession`. 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 `SpringSessionWebSession` that delegates to Spring Session's `Session`.
It looks something like the following:

====
[source, java]
----
public class SpringSessionWebSession implements WebSession {

	enum State {
		NEW, STARTED
	}

	private final S session;

	private AtomicReference<State> state = new AtomicReference<>();

	SpringSessionWebSession(S session, State state) {
		this.session = session;
		this.state.set(state);
	}

	@Override
	public void start() {
		this.state.compareAndSet(State.NEW, State.STARTED);
	}

	@Override
	public boolean isStarted() {
		State value = this.state.get();
		return (State.STARTED.equals(value)
				|| (State.NEW.equals(value) && !this.session.getAttributes().isEmpty()));
	}

	@Override
	public Mono<Void> changeSessionId() {
		return Mono.defer(() -> {
			this.session.changeSessionId();
			return save();
		});
	}

	// ... other methods delegate to the original Session
}
----
====

Next, we create a custom `WebSessionStore` that delegates to the `ReactiveSessionRepository` and wraps `Session` into custom `WebSession` implementation, as the following listing shows:

====
[source, java]
----
public class SpringSessionWebSessionStore<S extends Session> implements WebSessionStore {

	private final ReactiveSessionRepository<S> sessions;

	public SpringSessionWebSessionStore(ReactiveSessionRepository<S> reactiveSessionRepository) {
		this.sessions = reactiveSessionRepository;
	}

	// ...
}
----
====

To be detected by Spring WebFlux, this custom `WebSessionStore` needs to be registered with `ApplicationContext` as a bean named `webSessionManager`.
For additional information on Spring WebFlux, see the https://docs.spring.io/spring-framework/docs/{spring-framework-version}/reference/html/web-reactive.html[Spring Framework Reference Documentation].

[[spring-security]]
== Spring Security Integration

Spring Session provides integration with Spring Security.

[[spring-security-rememberme]]
=== Spring Security Remember-me Support

Spring Session provides integration with https://docs.spring.io/spring-security/site/docs/{spring-security-version}/reference/htmlsingle/#remember-me[Spring Security's Remember-me Authentication].
The support:

* Changes the session expiration length
* Ensures that the session cookie expires at `Integer.MAX_VALUE`.
The cookie expiration is set to the largest possible value, because the cookie is set only when the session is created.
If it were set to the same value as the session expiration, the session would get renewed when the user used it but the cookie expiration would not be updated (causing the expiration to be fixed).

To configure Spring Session with Spring Security in Java Configuration, you can use the following listing as a guide:

====
[source,java,indent=0]
----
include::{docs-test-dir}docs/security/RememberMeSecurityConfiguration.java[tags=http-rememberme]
	}

include::{docs-test-dir}docs/security/RememberMeSecurityConfiguration.java[tags=rememberme-bean]
----
====

An XML-based configuration would look something like the following:

====
[source,xml,indent=0]
----
include::{docs-test-resources-dir}docs/security/RememberMeSecurityConfigurationXmlTests-context.xml[tags=config]
----
====

[[spring-security-concurrent-sessions]]
=== Spring Security Concurrent Session Control


Spring Session provides integration with Spring Security to support its concurrent session control.
This allows limiting the number of active sessions that a single user can have concurrently, but, unlike the default
Spring Security support, this also works in a clustered environment. This is done by providing a custom
implementation of Spring Security's `SessionRegistry` interface.

When using Spring Security's Java config DSL, you can configure the custom `SessionRegistry` through the
`SessionManagementConfigurer`, as the following listing shows:

====
[source,java,indent=0]
----
include::{docs-test-dir}docs/security/SecurityConfiguration.java[tags=class]
----
====

This assumes that you have also configured Spring Session to provide a `FindByIndexNameSessionRepository` that
returns `Session` instances.

When using XML configuration, it would look something like the following listing:

====
[source,xml,indent=0]
----
include::{docs-test-resources-dir}docs/security/security-config.xml[tags=config]
----
====

This assumes that your Spring Session `SessionRegistry` bean is called `sessionRegistry`, which is the name used by all
`SpringHttpSessionConfiguration` subclasses.

[[spring-security-concurrent-sessions-limitations]]
=== Limitations

Spring Session's implementation of Spring Security's `SessionRegistry` interface does not support the `getAllPrincipals`
method, as this information cannot be retrieved by using Spring Session. This method is never called by Spring Security,
so this affects only applications that access the `SessionRegistry` themselves.

[[api]]
== API Documentation

You can browse the complete link:../../api/[Javadoc] online. The key APIs are described in the following sections:

* <<api-session>>
* <<api-sessionrepository>>
* <<api-findbyindexnamesessionrepository>>
* <<api-reactivesessionrepository>>
* <<api-enablespringhttpsession>>
* <<api-enablespringwebsession>>
* <<api-redisindexedsessionrepository>>
* <<api-reactiveredissessionrepository>>
* <<api-mapsessionrepository>>
* <<api-reactivemapsessionrepository>>
* <<api-jdbcindexedsessionrepository>>
* <<api-hazelcastindexedsessionrepository>>
* <<api-cookieserializer>>

[[api-session]]
=== Using `Session`

A `Session` is a simplified `Map` of name value pairs.

Typical usage might look like the following listing:

====
[source,java,indent=0]
----
include::{indexdoc-tests}[tags=repository-demo]
----

<1> We create a `SessionRepository` instance with a generic type, `S`, that extends `Session`. The generic type is defined in our class.
<2> We create a new `Session` by using our `SessionRepository` and assign it to a variable of type `S`.
<3> We interact with the `Session`. In our example, we demonstrate saving a `User` to the `Session`.
<4> We now save the `Session`. This is why we needed the generic type `S`. The `SessionRepository` only allows saving `Session` instances that were created or retrieved by using the same `SessionRepository`. This allows for the `SessionRepository` to make implementation specific optimizations (that is, writing only attributes that have changed).
<5> We retrieve the `Session` from the `SessionRepository`.
<6> We obtain the persisted `User` from our `Session` without the need for explicitly casting our attribute.
====

The `Session` API also provides attributes related to the `Session` instance's expiration.

Typical usage might look like the following listing:

====
[source,java,indent=0]
----
include::{indexdoc-tests}[tags=expire-repository-demo]
----

<1> We create a `SessionRepository` instance with a generic type, `S`, that extends `Session`. The generic type is defined in our class.
<2> We create a new `Session` by using our `SessionRepository` and assign it to a variable of type `S`.
<3> We interact with the `Session`.
In our example, we demonstrate updating the amount of time the `Session` can be inactive before it expires.
<4> We now save the `Session`.
This is why we needed the generic type, `S`.
The `SessionRepository` allows saving only `Session` instances that were created or retrieved using the same `SessionRepository`.
This allows for the `SessionRepository` to make implementation specific optimizations (that is, writing only attributes that have changed).
The last accessed time is automatically updated when the `Session` is saved.
<5> We retrieve the `Session` from the `SessionRepository`.
If the `Session` were expired, the result would be null.
====

[[api-sessionrepository]]
=== Using `SessionRepository`

A `SessionRepository` is in charge of creating, retrieving, and persisting `Session` instances.

If possible, you should not interact directly with a `SessionRepository` or a `Session`.
Instead, developers should prefer interacting with `SessionRepository` and `Session` indirectly through the <<httpsession,`HttpSession`>> and <<websocket,WebSocket>> integration.

[[api-findbyindexnamesessionrepository]]
=== Using `FindByIndexNameSessionRepository`

Spring Session's most basic API for using a `Session` is the `SessionRepository`.
This API is intentionally very simple, so that you can easily provide additional implementations with basic functionality.

Some `SessionRepository` implementations may also choose to implement `FindByIndexNameSessionRepository`.
For example, Spring's Redis, JDBC, and Hazelcast support libraries all implement `FindByIndexNameSessionRepository`.

The `FindByIndexNameSessionRepository` provides a method to look up all the sessions with a given index name and index value.
As a common use case that is supported by all provided `FindByIndexNameSessionRepository` implementations, you can use a convenient method to look up all the sessions for a particular user.
This is done by ensuring that the session attribute with the name of `FindByIndexNameSessionRepository.PRINCIPAL_NAME_INDEX_NAME` is populated with the username.
It is your responsibility to ensure that the attribute is populated, since Spring Session is not aware of the authentication mechanism being used.
An example of how to use this can be seen in the following listing:

====
[source,java,indent=0]
----
include::{docs-test-dir}docs/FindByIndexNameSessionRepositoryTests.java[tags=set-username]
----
====

NOTE: Some implementations of `FindByIndexNameSessionRepository` provide hooks to automatically index other session attributes.
For example, many implementations automatically ensure that the current Spring Security user name is indexed with the index name of `FindByIndexNameSessionRepository.PRINCIPAL_NAME_INDEX_NAME`.

Once the session is indexed, you can find by using code similar to the following:

====
[source,java,indent=0]
----
include::{docs-test-dir}docs/FindByIndexNameSessionRepositoryTests.java[tags=findby-username]
----
====

[[api-reactivesessionrepository]]
=== Using `ReactiveSessionRepository`

A `ReactiveSessionRepository` is in charge of creating, retrieving, and persisting `Session` instances in a non-blocking and reactive manner.

If possible, you should not interact directly with a `ReactiveSessionRepository` or a `Session`.
Instead, you should prefer interacting with `ReactiveSessionRepository` and `Session` indirectly through the <<websession,WebSession>> integration.

[[api-enablespringhttpsession]]
=== Using `@EnableSpringHttpSession`

You can add the `@EnableSpringHttpSession` annotation to a `@Configuration` class to expose the `SessionRepositoryFilter` as a bean named `springSessionRepositoryFilter`.
In order to use the annotation, you must provide a single `SessionRepository` bean.
The following example shows how to do so:

====
[source,java,indent=0]
----
include::{docs-test-dir}docs/SpringHttpSessionConfig.java[tags=class]
----
====

Note that no infrastructure for session expirations is configured for you.
This is because things such as session expiration are highly implementation-dependent.
This means that, if you need to clean up expired sessions, you are responsible for cleaning up the expired sessions.

[[api-enablespringwebsession]]
=== Using `@EnableSpringWebSession`

You can add the `@EnableSpringWebSession` annotation to a `@Configuration` class to expose the `WebSessionManager` as a bean named `webSessionManager`.
To use the annotation, you must provide a single `ReactiveSessionRepository` bean.
The following example shows how to do so:

====
[source,java,indent=0]
----
include::{docs-test-dir}docs/SpringWebSessionConfig.java[tags=class]
----
====

Note that no infrastructure for session expirations is configured for you.
This is because things such as session expiration are highly implementation-dependent.
This means that, if you require cleaning up expired sessions, you are responsible for cleaning up the expired sessions.

[[api-redisindexedsessionrepository]]
=== Using `RedisIndexedSessionRepository`

`RedisIndexedSessionRepository` is a `SessionRepository` that is implemented by using Spring Data's `RedisOperations`.
In a web environment, this is typically used in combination with `SessionRepositoryFilter`.
The implementation supports `SessionDestroyedEvent` and `SessionCreatedEvent` through `SessionMessageListener`.

[[api-redisindexedsessionrepository-new]]
==== Instantiating a `RedisIndexedSessionRepository`

You can see a typical example of how to create a new instance in the following listing:

====
[source,java,indent=0]
----
include::{indexdoc-tests}[tags=new-redisindexedsessionrepository]
----
====

For additional information on how to create a `RedisConnectionFactory`, see the Spring Data Redis Reference.

[[api-redisindexedsessionrepository-config]]
==== Using `@EnableRedisHttpSession`

In a web environment, the simplest way to create a new `RedisIndexedSessionRepository` is to use `@EnableRedisHttpSession`.
You can find complete example usage in the <<samples>>.
You can use the following attributes to customize the configuration:

* *maxInactiveIntervalInSeconds*: The amount of time before the session expires, in seconds.
* *redisNamespace*: Allows configuring an application specific namespace for the sessions. Redis keys and channel IDs start with the prefix of `<redisNamespace>:`.
* *flushMode*: Allows specifying when data is written to Redis. The default is only when `save` is invoked on `SessionRepository`.
A value of `FlushMode.IMMEDIATE` writes to Redis as soon as possible.

===== Custom `RedisSerializer`

You can customize the serialization by creating a bean named `springSessionDefaultRedisSerializer` that implements `RedisSerializer<Object>`.

==== Redis `TaskExecutor`

`RedisIndexedSessionRepository` is subscribed to receive events from Redis by using a `RedisMessageListenerContainer`.
You can customize the way those events are dispatched by creating a bean named `springSessionRedisTaskExecutor`, a bean `springSessionRedisSubscriptionExecutor`, or both.
You can find more details on configuring Redis task executors https://docs.spring.io/spring-data-redis/docs/{spring-data-redis-version}/reference/html/#redis:pubsub:subscribe:containers[here].

[[api-redisindexedsessionrepository-storage]]
==== Storage Details

The following sections outline how Redis is updated for each operation.
The following example shows an example of creating a new session:

====
----
HMSET spring:session:sessions:33fdd1b6-b496-4b33-9f7d-df96679d32fe creationTime 1404360000000 \
	maxInactiveInterval 1800 \
	lastAccessedTime 1404360000000 \
	sessionAttr:attrName someAttrValue \
	sessionAttr:attrName2 someAttrValue2
EXPIRE spring:session:sessions:33fdd1b6-b496-4b33-9f7d-df96679d32fe 2100
APPEND spring:session:sessions:expires:33fdd1b6-b496-4b33-9f7d-df96679d32fe ""
EXPIRE spring:session:sessions:expires:33fdd1b6-b496-4b33-9f7d-df96679d32fe 1800
SADD spring:session:expirations:1439245080000 expires:33fdd1b6-b496-4b33-9f7d-df96679d32fe
EXPIRE spring:session:expirations1439245080000 2100
----
====

The subsequent sections describe the details.

===== Saving a Session

Each session is stored in Redis as a `Hash`.
Each session is set and updated by using the `HMSET` command.
The following example shows how each session is stored:

====
----
HMSET spring:session:sessions:33fdd1b6-b496-4b33-9f7d-df96679d32fe creationTime 1404360000000 \
	maxInactiveInterval 1800 \
	lastAccessedTime 1404360000000 \
	sessionAttr:attrName someAttrValue \
	sessionAttr:attrName2 someAttrValue2
----
====

In the preceding example, the following statements are true about the session:

* The session ID is 33fdd1b6-b496-4b33-9f7d-df96679d32fe.
* The session was created at 1404360000000 (in milliseconds since midnight of 1/1/1970 GMT).
* The session expires in 1800 seconds (30 minutes).
* The session was last accessed at 1404360000000 (in milliseconds since midnight of 1/1/1970 GMT).
* The session has two attributes.
The first is `attrName`, with a value of `someAttrValue`.
The second session attribute is named `attrName2`, with a value of `someAttrValue2`.

[[api-redisindexedsessionrepository-writes]]
===== Optimized Writes

The `Session` instances managed by `RedisIndexedSessionRepository` keeps track of the properties that have changed and updates only those.
This means that, if an attribute is written once and read many times, we need to write that attribute only once.
For example, assume the `attrName2` session attribute from the lsiting in the preceding section was updated.
The following command would be run upon saving:

====
----
HMSET spring:session:sessions:33fdd1b6-b496-4b33-9f7d-df96679d32fe sessionAttr:attrName2 newValue
----
====

[[api-redisindexedsessionrepository-expiration]]
===== Session Expiration

An expiration is associated with each session by using the `EXPIRE` command, based upon the `Session.getMaxInactiveInterval()`.
The following example shows a typical `EXPIRE` command:

====
----
EXPIRE spring:session:sessions:33fdd1b6-b496-4b33-9f7d-df96679d32fe 2100
----
====

Note that the expiration that is set to five minutes after the session actually expires.
This is necessary so that the value of the session can be accessed when the session expires.
An expiration is set on the session itself five minutes after it actually expires to ensure that it is cleaned up, but only after we perform any necessary processing.

NOTE: The `SessionRepository.findById(String)` method ensures that no expired sessions are returned.
This means that you need not check the expiration before using a session.

Spring Session relies on the delete and expired https://redis.io/topics/notifications[keyspace notifications] from Redis to fire a <<api-redisindexedsessionrepository-sessiondestroyedevent,`SessionDeletedEvent`>> and a <<api-redisindexedsessionrepository-sessiondestroyedevent,`SessionExpiredEvent`>>, respectively.
`SessionDeletedEvent` or `SessionExpiredEvent` ensure that resources associated with the `Session` are cleaned up.
For example, when you use Spring Session's WebSocket support, the Redis expired or delete event triggers any WebSocket connections associated with the session to be closed.

Expiration is not tracked directly on the session key itself, since this would mean the session data would no longer be available. Instead, a special session expires key is used. In the preceding example, the expires key is as follows:

====
----
APPEND spring:session:sessions:expires:33fdd1b6-b496-4b33-9f7d-df96679d32fe ""
EXPIRE spring:session:sessions:expires:33fdd1b6-b496-4b33-9f7d-df96679d32fe 1800
----
====

When a session expires key is deleted or expires, the keyspace notification triggers a lookup of the actual session, and a `SessionDestroyedEvent` is fired.

One problem with relying on Redis expiration exclusively is that, if the key has not been accessed, Redis makes no guarantee of when the expired event is fired.
Specifically, the background task that Redis uses to clean up expired keys is a low-priority task and may not trigger the key expiration.
For additional details, see the https://redis.io/topics/notifications[Timing of Expired Events] section in the Redis documentation.

To circumvent the fact that expired events are not guaranteed to happen, we can ensure that each key is accessed when it is expected to expire.
This means that, if the TTL is expired on the key, Redis removes the key and fires the expired event when we try to access the key.

For this reason, each session expiration is also tracked to the nearest minute.
This lets a background task access the potentially expired sessions to ensure that Redis expired events are fired in a more deterministic fashion.
The following example shows these events:

====
----
SADD spring:session:expirations:1439245080000 expires:33fdd1b6-b496-4b33-9f7d-df96679d32fe
EXPIRE spring:session:expirations1439245080000 2100
----
====

The background task then uses these mappings to explicitly request each key.
By accessing the key, rather than deleting it, we ensure that Redis deletes the key for us only if the TTL is expired.

NOTE: We do not explicitly delete the keys, since, in some instances, there may be a race condition that incorrectly identifies a key as expired when it is not.
Short of using distributed locks (which would kill our performance), there is no way to ensure the consistency of the expiration mapping.
By simply accessing the key, we ensure that the key is only removed if the TTL on that key is expired.


[[api-redisindexedsessionrepository-sessiondestroyedevent]]
==== `SessionDeletedEvent` and `SessionExpiredEvent`

`SessionDeletedEvent` and `SessionExpiredEvent` are both types of `SessionDestroyedEvent`.

`RedisIndexedSessionRepository` supports firing a `SessionDeletedEvent` when a `Session` is deleted or a `SessionExpiredEvent` when a `Session` expires.
This is necessary to ensure resources associated with the `Session` are properly cleaned up.

For example, when integrating with WebSockets, the `SessionDestroyedEvent` is in charge of closing any active WebSocket connections.

Firing `SessionDeletedEvent` or `SessionExpiredEvent` is made available through the `SessionMessageListener`, which listens to https://redis.io/topics/notifications[Redis Keyspace events].
In order for this to work, Redis Keyspace events for Generic commands and Expired events needs to be enabled.
The following example shows how to do so:

====
[source,bash]
----
redis-cli config set notify-keyspace-events Egx
----
====

If you use `@EnableRedisHttpSession`, managing the `SessionMessageListener` and enabling the necessary Redis Keyspace events is done automatically.
However, in a secured Redis enviornment, the config command is disabled.
This means that Spring Session cannot configure Redis Keyspace events for you.
To disable the automatic configuration, add `ConfigureRedisAction.NO_OP` as a bean.

For example, with Java configuration, you can use the following:

====
[source,java,indent=0]
----
include::{docs-test-dir}docs/RedisHttpSessionConfigurationNoOpConfigureRedisActionTests.java[tags=configure-redis-action]
----
====

In XML configuration, you can use the following:

====
[source,xml,indent=0]
----
include::{docs-test-resources-dir}docs/HttpSessionConfigurationNoOpConfigureRedisActionXmlTests-context.xml[tags=configure-redis-action]
----
====

[[api-redisindexedsessionrepository-sessioncreatedevent]]
==== Using `SessionCreatedEvent`

When a session is created, an event is sent to Redis with a channel ID of `spring:session:channel:created:33fdd1b6-b496-4b33-9f7d-df96679d32fe`,
where `33fdd1b6-b496-4b33-9f7d-df96679d32fe` is the session ID. The body of the event is the session that was created.

If registered as a `MessageListener` (the default), `RedisIndexedSessionRepository` then translates the Redis message into a `SessionCreatedEvent`.

[[api-redisindexedsessionrepository-cli]]
==== Viewing the Session in Redis

After https://redis.io/topics/quickstart[installing redis-cli], you can inspect the values in Redis https://redis.io/commands#hash[using the redis-cli].
For example, you can enter the following into a terminal:

====
[source,bash]
----
$ redis-cli
redis 127.0.0.1:6379> keys *
1) "spring:session:sessions:4fc39ce3-63b3-4e17-b1c4-5e1ed96fb021" <1>
2) "spring:session:expirations:1418772300000" <2>
----

<1> The suffix of this key is the session identifier of the Spring Session.
<2> This key contains all the session IDs that should be deleted at the time `1418772300000`.
====

You can also view the attributes of each session.
The following example shows how to do so:

====
[source,bash]
----
redis 127.0.0.1:6379> hkeys spring:session:sessions:4fc39ce3-63b3-4e17-b1c4-5e1ed96fb021
1) "lastAccessedTime"
2) "creationTime"
3) "maxInactiveInterval"
4) "sessionAttr:username"
redis 127.0.0.1:6379> hget spring:session:sessions:4fc39ce3-63b3-4e17-b1c4-5e1ed96fb021 sessionAttr:username
"\xac\xed\x00\x05t\x00\x03rob"
----
====

[[api-reactiveredissessionrepository]]
=== Using `ReactiveRedisSessionRepository`

`ReactiveRedisSessionRepository` is a `ReactiveSessionRepository` that is implemented by using Spring Data's `ReactiveRedisOperations`.
In a web environment, this is typically used in combination with `WebSessionStore`.

[[api-reactiveredissessionrepository-new]]
==== Instantiating a `ReactiveRedisSessionRepository`

The following example shows how to create a new instance:

====
[source,java,indent=0]
----
include::{indexdoc-tests}[tags=new-reactiveredissessionrepository]
----
====

For additional information on how to create a `ReactiveRedisConnectionFactory`, see the Spring Data Redis Reference.

[[api-reactiveredissessionrepository-config]]
==== Using `@EnableRedisWebSession`

In a web environment, the simplest way to create a new `ReactiveRedisSessionRepository` is to use `@EnableRedisWebSession`.
You can use the following attributes to customize the configuration:

* *maxInactiveIntervalInSeconds*: The amount of time before the session expires, in seconds
* *redisNamespace*: Allows configuring an application specific namespace for the sessions. Redis keys and channel IDs start with q prefix of `<redisNamespace>:`.
* *flushMode*: Allows specifying when data is written to Redis. The default is only when `save` is invoked on `ReactiveSessionRepository`.
A value of `FlushMode.IMMEDIATE` writes to Redis as soon as possible.

[[api-reactiveredissessionrepository-writes]]
===== Optimized Writes

The `Session` instances managed by `ReactiveRedisSessionRepository` keep track of the properties that have changed and updates only those.
This means that, if an attribute is written once and read many times, we need to write that attribute only once.

[[api-reactiveredissessionrepository-cli]]
==== Viewing the Session in Redis

After https://redis.io/topics/quickstart[installing redis-cli], you can inspect the values in Redis https://redis.io/commands#hash[using the redis-cli].
For example, you can enter the following command into a terminal window:

====
[source,bash]
----
$ redis-cli
redis 127.0.0.1:6379> keys *
1) "spring:session:sessions:4fc39ce3-63b3-4e17-b1c4-5e1ed96fb021" <1>
----

<1> The suffix of this key is the session identifier of the Spring Session.
====

You can also view the attributes of each session by using the `hkeys` command.
The following example shows how to do so:

====
[source,bash]
----
redis 127.0.0.1:6379> hkeys spring:session:sessions:4fc39ce3-63b3-4e17-b1c4-5e1ed96fb021
1) "lastAccessedTime"
2) "creationTime"
3) "maxInactiveInterval"
4) "sessionAttr:username"
redis 127.0.0.1:6379> hget spring:session:sessions:4fc39ce3-63b3-4e17-b1c4-5e1ed96fb021 sessionAttr:username
"\xac\xed\x00\x05t\x00\x03rob"
----
====

[[api-mapsessionrepository]]
=== Using `MapSessionRepository`

The `MapSessionRepository` allows for persisting `Session` in a `Map`, with the key being the `Session` ID and the value being the `Session`.
You can use the implementation with a `ConcurrentHashMap` as a testing or convenience mechanism.
Alternatively, you can use it with distributed `Map` implementations. For example, it can be used with Hazelcast.

[[api-mapsessionrepository-new]]
==== Instantiating `MapSessionRepository`

The following example shows how to create a new instance:

====
[source,java,indent=0]
----
include::{indexdoc-tests}[tags=new-mapsessionrepository]
----
====

[[api-mapsessionrepository-hazelcast]]
==== Using Spring Session and Hazlecast

The <<samples,Hazelcast Sample>> is a complete application that demonstrates how to use Spring Session with Hazelcast.

To run it, use the following command:

====
----
	./gradlew :samples:hazelcast:tomcatRun
----
====

The <<samples,Hazelcast Spring Sample>> is a complete application that demonstrates how to use Spring Session with Hazelcast and Spring Security.

It includes example Hazelcast `MapListener` implementations that support firing `SessionCreatedEvent`, `SessionDeletedEvent`, and `SessionExpiredEvent`.

To run it, use the following command:

====
----
	./gradlew :samples:hazelcast-spring:tomcatRun
----
====

[[api-reactivemapsessionrepository]]
=== Using `ReactiveMapSessionRepository`

The `ReactiveMapSessionRepository` allows for persisting `Session` in a `Map`, with the key being the `Session` ID and the value being the `Session`.
You can use the implementation with a `ConcurrentHashMap` as a testing or convenience mechanism.
Alternatively, you can use it with distributed `Map` implementations, with the requirement that the supplied `Map` must be non-blocking.

[[api-jdbcindexedsessionrepository]]
=== Using `JdbcIndexedSessionRepository`

`JdbcIndexedSessionRepository` is a `SessionRepository` implementation that uses Spring's `JdbcOperations` to store sessions in a relational database.
In a web environment, this is typically used in combination with `SessionRepositoryFilter`.
Note that this implementation does not support publishing of session events.

[[api-jdbcindexedsessionrepository-new]]
==== Instantiating a `JdbcIndexedSessionRepository`

The following example shows how to create a new instance:

====
[source,java,indent=0]
----
include::{indexdoc-tests}[tags=new-jdbcindexedsessionrepository]
----
====

For additional information on how to create and configure `JdbcTemplate` and `PlatformTransactionManager`, see the https://docs.spring.io/spring/docs/{spring-framework-version}/spring-framework-reference/data-access.html[Spring Framework Reference Documentation].

[[api-jdbcindexedsessionrepository-config]]
==== Using `@EnableJdbcHttpSession`

In a web environment, the simplest way to create a new `JdbcIndexedSessionRepository` is to use `@EnableJdbcHttpSession`.
You can find complete example usage in the <<samples>>
You can use the following attributes to customize the configuration:

* *tableName*: The name of database table used by Spring Session to store sessions
* *maxInactiveIntervalInSeconds*: The amount of time before the session will expire in seconds

===== Customizing `LobHandler`

You can customize BLOB handling by creating a bean named `springSessionLobHandler` that implements `LobHandler`.

===== Customizing `ConversionService`

You can customize the default serialization and deserialization of the session by providing a `ConversionService` instance.
When working in a typical Spring environment, the default `ConversionService` bean (named `conversionService`) is automatically picked up and used for serialization and deserialization.
However, you can override the default `ConversionService` by providing a bean named `springSessionConversionService`.

[[api-jdbcindexedsessionrepository-storage]]
==== Storage Details

By default, this implementation uses `SPRING_SESSION` and `SPRING_SESSION_ATTRIBUTES` tables to store sessions.
Note that you can customize the table name, as already described. In that case, the table used to store attributes is named by using the provided table name suffixed with `_ATTRIBUTES`.
If further customizations are needed, you can customize the SQL queries used by the repository by using `set*Query` setter methods. In this case, you need to manually configure the `sessionRepository` bean.

Due to the differences between the various database vendors, especially when it comes to storing binary data, make sure to use SQL scripts specific to your database.
Scripts for most major database vendors are packaged as `org/springframework/session/jdbc/schema-\*.sql`, where `*` is the target database type.

For example, with PostgreSQL, you can use the following schema script:

====
[source,sql,indent=0]
----
include::{session-jdbc-main-resources-dir}org/springframework/session/jdbc/schema-postgresql.sql[]
----
====

With MySQL database, you can use the following script:

====
[source,sql,indent=0]
----
include::{session-jdbc-main-resources-dir}org/springframework/session/jdbc/schema-mysql.sql[]
----
====

==== Transaction Management

All JDBC operations in `JdbcIndexedSessionRepository` are performed in a transactional manner.
Transactions are performed with propagation set to `REQUIRES_NEW` in order to avoid unexpected behavior due to interference with existing transactions (for example, running a `save` operation in a thread that already participates in a read-only transaction).

[[api-hazelcastindexedsessionrepository]]
=== Using `HazelcastIndexedSessionRepository`

`HazelcastIndexedSessionRepository` is a `SessionRepository` implementation that stores sessions in Hazelcast's distributed `IMap`.
In a web environment, this is typically used in combination with `SessionRepositoryFilter`.

[[api-hazelcastindexedsessionrepository-new]]
==== Instantiating a `HazelcastIndexedSessionRepository`

The following example shows how to create a new instance:

====
[source,java,indent=0]
----
include::{indexdoc-tests}[tags=new-hazelcastindexedsessionrepository]
----
====

For additional information on how to create and configure Hazelcast instance, see the https://docs.hazelcast.org/docs/{hazelcast-version}/manual/html-single/index.html#hazelcast-configuration[Hazelcast documentation].

[[api-enablehazelcasthttpsession]]
==== Using `@EnableHazelcastHttpSession`

To use https://hazelcast.org/[Hazelcast] as your backing source for the `SessionRepository`, you can add the `@EnableHazelcastHttpSession` annotation to a `@Configuration` class.
Doing so extends the functionality provided by the `@EnableSpringHttpSession` annotation but makes the `SessionRepository` for you in Hazelcast.
You must provide a single `HazelcastInstance` bean for the configuration to work.
You can find a complete configuration example in the <<samples>>.

[[api-enablehazelcasthttpsession-customize]]
==== Basic Customization
You can use the following attributes on `@EnableHazelcastHttpSession` to customize the configuration:

* *maxInactiveIntervalInSeconds*: The amount of time before the session expires, in seconds. The default is 1800 seconds (30 minutes)
* *sessionMapName*: The name of the distributed `Map` that is used in Hazelcast to store the session data.

[[api-enablehazelcasthttpsession-events]]
==== Session Events

Using a `MapListener` to respond to entries being added, evicted, and removed from the distributed `Map` causes these events to trigger publishing of `SessionCreatedEvent`, `SessionExpiredEvent`, and `SessionDeletedEvent` events (respectively) through the `ApplicationEventPublisher`.

[[api-enablehazelcasthttpsession-storage]]
==== Storage Details

Sessions are stored in a distributed `IMap` in Hazelcast.
The `IMap` interface methods are used to `get()` and `put()` Sessions.
Additionally, the `values()` method supports a `FindByIndexNameSessionRepository#findByIndexNameAndIndexValue` operation, together with appropriate `ValueExtractor` (which needs to be registered with Hazelcast). See the <<samples, Hazelcast Spring Sample>> for more details on this configuration.
The expiration of a session in the `IMap` is handled by Hazelcast's support for setting the time to live on an entry when it is `put()` into the `IMap`. Entries (sessions) that have been idle longer than the time to live are automatically removed from the `IMap`.

You should not need to configure any settings such as `max-idle-seconds` or `time-to-live-seconds` for the `IMap` within the Hazelcast configuration.

Note that if you use Hazelcast's `MapStore` to persist your sessions `IMap`, the following limitations apply when reloading the sessions from `MapStore`:

* Reloading triggers `EntryAddedListener` results in `SessionCreatedEvent` being re-published
* Reloading uses default TTL for a given `IMap` results in sessions losing their original TTL

[[api-cookieserializer]]
=== Using `CookieSerializer`

A `CookieSerializer` is responsible for defining how the session cookie is written.
Spring Session comes with a default implementation using `DefaultCookieSerializer`.

[[api-cookieserializer-bean]]
==== Exposing `CookieSerializer` as a bean
Exposing the `CookieSerializer` as a Spring bean augments the existing configuration when you use configurations like `@EnableRedisHttpSession`.

The following example shows how to do so:

====
[source,java]
----
include::{samples-dir}spring-session-sample-javaconfig-custom-cookie/src/main/java/sample/Config.java[tags=cookie-serializer]
----

<1> We customize the name of the cookie to be `JSESSIONID`.
<2> We customize the path of the cookie to be `/` (rather than the default of the context root).
<3> We customize the domain name pattern (a regular expression) to be `^.+?\\.(\\w+\\.[a-z]+)$`.
This allows sharing a session across domains and applications.
If the regular expression does not match, no domain is set and the existing domain is used.
If the regular expression matches, the first https://docs.oracle.com/javase/tutorial/essential/regex/groups.html[grouping] is used as the domain.
This means that a request to https://child.example.com sets the domain to `example.com`.
However, a request to http://localhost:8080/ or https://192.168.1.100:8080/ leaves the cookie unset and, thus, still works in development without any changes being necessary for production.
====

WARNING: You should only match on valid domain characters, since the domain name is reflected in the response.
Doing so prevents a malicious user from performing such attacks as https://en.wikipedia.org/wiki/HTTP_response_splitting[HTTP Response Splitting].

[[api-cookieserializer-customization]]
==== Customizing `CookieSerializer`

You can customize how the session cookie is written by using any of the following configuration options on the `DefaultCookieSerializer`.

* `cookieName`: The name of the cookie to use.
Default: `SESSION`.
* `useSecureCookie`: Specifies whether a secure cookie should be used.
Default: Use the value of `HttpServletRequest.isSecure()` at the time of creation.
* `cookiePath`: The path of the cookie.
Default: The context root.
* `cookieMaxAge`: Specifies the max age of the cookie to be set at the time the session is created.
Default: `-1`, which indicates the cookie should be removed when the browser is closed.
* `jvmRoute`: Specifies a suffix to be appended to the session ID and included in the cookie.
Used to identify which JVM to route to for session affinity.
With some implementations (that is, Redis) this option provides no performance benefit.
However, it can help with tracing logs of a particular user.
* `domainName`: Allows specifying a specific domain name to be used for the cookie.
This option is simple to understand but often requires a different configuration between development and production environments.
See `domainNamePattern` as an alternative.
* `domainNamePattern`: A case-insensitive pattern used to extract the domain name from the `HttpServletRequest#getServerName()`.
The pattern should provide a single grouping that is used to extract the value of the cookie domain.
If the regular expression does not match, no domain is set and the existing domain is used.
If the regular expression matches, the first https://docs.oracle.com/javase/tutorial/essential/regex/groups.html[grouping] is used as the domain.
* `sameSite`: The value for the `SameSite` cookie directive.
To disable the serialization of the `SameSite` cookie directive, you may set this value to `null`.
Default: `Lax`

WARNING: You should only match on valid domain characters, since the domain name is reflected in the response.
Doing so prevents a malicious user from performing such attacks as https://en.wikipedia.org/wiki/HTTP_response_splitting[HTTP Response Splitting].

[[custom-sessionrepository]]
== Customizing `SessionRepository`

Implementing a custom <<api-sessionrepository,`SessionRepository`>> API should be a fairly straightforward task.
Coupling the custom implementation with <<api-enablespringhttpsession,`@EnableSpringHttpSession`>> support lets you reuse existing Spring Session configuration facilities and infrastructure.
There are, however, a couple of aspects that deserve closer consideration.

During the lifecycle of an HTTP request, the `HttpSession` is typically persisted to `SessionRepository` twice.
The first persist operation is to ensure that the session is available to the client as soon as the client has access to the session ID, and it is also necessary to write after the session is committed because further modifications to the session might be made.
Having this in mind, we generally recommend that a `SessionRepository` implementation keep track of changes to ensure that only deltas are saved.
This is particularly important in highly concurrent environments, where multiple requests operate on the same `HttpSession` and, therefore, cause race conditions, with requests overriding each other's changes to session attributes.
All of the `SessionRepository` implementations provided by Spring Session use the described approach to persist session changes and can be used for guidance when you implement custom `SessionRepository`.

Note that the same recommendations apply for implementing a custom <<api-reactivesessionrepository,`ReactiveSessionRepository`>> as well.
In this case, you should use the <<api-enablespringwebsession,`@EnableSpringWebSession`>>.

[[upgrading-2.0]]
== Upgrading to 2.x

With the new major release version, the Spring Session team took the opportunity to make some non-passive changes.
The focus of these changes is to improve and harmonize Spring Session's APIs as well as remove the deprecated components.

=== Baseline Update

Spring Session 2.0 requires Java 8 and Spring Framework 5.0 as a baseline, since its entire codebase is now based on Java 8 source code.
See https://github.com/spring-projects/spring-framework/wiki/Upgrading-to-Spring-Framework-5.x[Upgrading to Spring Framework 5.x] for more on upgrading Spring Framework.

=== Replaced and Removed Modules

As a part of the project's splitting of the modules, the existing `spring-session` has been replaced with the `spring-session-core` module.
The `spring-session-core` module holds only the common set of APIs and components, while other modules contain the implementation of the appropriate `SessionRepository` and functionality related to that data store.
This applies to several existing modules that were previously a simple dependency aggregator helper module.
With new module arrangement, the following modules actually carry the implementation:

* Spring Session Data Redis
* Spring Session JDBC
* Spring Session Hazelcast

Also, the following modules were removed from the main project repository:

* Spring Session Data MongoDB
* Spring Session Data GemFire

Note that these two have moved to separate repositories and continue to be available under new artifact names:

* https://github.com/spring-projects/spring-session-data-mongodb[`spring-session-data-mongodb`]
* https://github.com/spring-projects/spring-session-data-geode[`spring-session-data-geode`]

=== Replaced and Removed Packages, Classes, and Methods

The following changes were made to packages, classes, and methods:

* `ExpiringSession` API has been merged into the `Session` API.
* The `Session` API has been enhanced to make full use of Java 8.
* The `Session` API has been extended with `changeSessionId` support.
* The `SessionRepository` API has been updated to better align with Spring Data method naming conventions.
* `AbstractSessionEvent` and its subclasses are no longer constructable without an underlying `Session` object.
* The Redis namespace used by `RedisOperationsSessionRepository` is now fully configurable, instead of being partially configurable.
* Redis configuration support has been updated to avoid registering a Spring Session-specific `RedisTemplate` bean.
* JDBC configuration support has been updated to avoid registering a Spring Session-specific `JdbcTemplate` bean.
* Previously deprecated classes and methods have been removed across the codebase

=== Dropped Support

As a part of the changes to `HttpSessionStrategy` and its alignment to the counterpart from the reactive world, the support for managing multiple users' sessions in a single browser instance has been removed.
The introduction of a new API to replace this functionality is under consideration for future releases.

[[community]]
== Spring Session Community

We are glad to consider you a part of our community.
The following sections provide additional about how to interact with the Spring Session community.

[[community-support]]
=== Support

You can get help by asking questions on https://stackoverflow.com/questions/tagged/spring-session[Stack Overflow with the `spring-session` tag].
Similarly, we encourage helping others by answering questions on Stack Overflow.

[[community-source]]
=== Source Code

You can find the source code on GitHub at https://github.com/spring-projects/spring-session/

[[community-issues]]
=== Issue Tracking

We track issues in GitHub issues at https://github.com/spring-projects/spring-session/issues

[[community-contributing]]
=== Contributing

We appreciate https://help.github.com/articles/using-pull-requests/[pull requests].

[[community-license]]
=== License

Spring Session is Open Source software released under the https://www.apache.org/licenses/LICENSE-2.0[Apache 2.0 license].

[[community-extensions]]
=== Community Extensions

|===
| Name | Location

| Spring Session Infinispan
| https://infinispan.org/infinispan-spring-boot/master/spring_boot_starter.html#_enabling_spring_session_support

|===

[[minimum-requirements]]
== Minimum Requirements

The minimum requirements for Spring Session are:

* Java 8+.
* If you run in a Servlet Container (not required), Servlet 3.1+.
* If you use other Spring libraries (not required), the minimum required version is Spring 5.0.x.
* `@EnableRedisHttpSession` requires Redis 2.8+. This is necessary to support <<api-redisindexedsessionrepository-expiration,Session Expiration>>
* `@EnableHazelcastHttpSession` requires Hazelcast 3.6+. This is necessary to support <<api-enablehazelcasthttpsession-storage,`FindByIndexNameSessionRepository`>>

NOTE: At its core, Spring Session has a required dependency only on `spring-jcl`.
For an example of using Spring Session without any other Spring dependencies, see the <<samples,hazelcast sample>> application.
