On this page
Session
By default, Micronaut is a stateless HTTP server, however depending on your application requirements you may need the notion of HTTP sessions.
For Micronaut Session 5.x, HttpSessionFilter is a method-based @ServerFilter and no longer implements HttpServerFilter.
Micronaut provides this module inspired by Spring Session that enables this which currently has two implementations:
-
In-Memory sessions - which you should combine with a sticky session proxy if you plan to run multiple instances.
-
Redis sessions - In this case Redis stores sessions, and non-blocking I/O is used to read/write sessions to Redis.
The core of Micronaut Session implementation is io.micronaut.session.http.HttpSessionFilter.
The following configuration options are available for the SessionFilter Filter:
To enable support for in-memory sessions you just need the micronaut-session dependency:
implementation("io.micronaut.session:micronaut-session")To store Session instances in Redis, use the Micronaut Redis module which includes detailed instructions.
To quickly get up and running with Redis sessions you must also have the redis-lettuce dependency in your build:
compile "io.micronaut-session:micronaut-session"
compile "io.micronaut.redis:micronaut-redis-lettuce"And enable Redis sessions via configuration in the application configuration file:
redis.uri=redis://localhost:6379
micronaut.session.http.redis.enabled=trueSession resolution can be configured with HttpSessionConfiguration.
By default, sessions are resolved using an HttpSessionFilter that looks for session identifiers via either an HTTP header (using the Authorization-Info or X-Auth-Token headers) or via a Cookie named SESSION.
You can disable either header resolution or cookie resolution via configuration in the application configuration file:
micronaut.session.http.cookie=false
micronaut.session.http.header=trueThe above configuration enables header resolution, but disables cookie resolution. You can also configure header and cookie names.
A Session can be retrieved with a parameter of type Session in a controller method. For example consider the following controller:
Note that because the Session is declared as a required parameter, to execute the controller action a Session will be created and saved to the SessionStore.
If you don’t want to create unnecessary sessions, declare the Session as @Nullable in which case a session will not be created and saved unnecessarily. For example:
@Post("/cart/clear")
void clearCart(@Nullable Session session) {
if (session != null) {
session.remove(ATTR_CART);
}
}The above method only injects a new Session if one already exists.
If the client is a web browser, sessions should work if cookies are enabled. However, for programmatic HTTP clients you need to propagate the session ID between HTTP calls.
For example, when invoking the viewCart method of the StoreController in the previous example, the HTTP client receives by default a AUTHORIZATION_INFO header. The following example demonstrates this:
You can then pass this AUTHORIZATION_INFO in subsequent requests to reuse the existing Session:
Rather than explicitly injecting the Session into a controller method, you can instead use @SessionValue. For example:
You can register ApplicationEventListener beans to listen for Session related events located in the io.micronaut.session.event package.
The following table summarizes the events:
| Type | Description |
|---|---|
Fired when a Session is created |
|
Fired when a Session is deleted |
|
Fired when a Session expires |
|
Parent of both |
For this project, you can find a list of releases (with release notes) here:
You can find the source code of this project in this repository: