150 lines
5.9 KiB
Plaintext
150 lines
5.9 KiB
Plaintext
= Spring Session - WebSocket
|
|
Rob Winch
|
|
:toc: left
|
|
:websocketdoc-test-dir: {docs-test-dir}docs/websocket/
|
|
:stylesdir: ../
|
|
:highlightjsdir: ../js/highlight
|
|
:docinfodir: guides
|
|
|
|
This guide describes how to use Spring Session to ensure that WebSocket messages keep your HttpSession alive.
|
|
|
|
// tag::disclaimer[]
|
|
|
|
NOTE: Spring Session's WebSocket support works only with Spring's WebSocket support.
|
|
Specifically,it does not work with using https://www.jcp.org/en/jsr/detail?id=356[JSR-356] directly, because JSR-356 does not have a mechanism for intercepting incoming WebSocket messages.
|
|
|
|
// end::disclaimer[]
|
|
|
|
[#index-link]
|
|
link:../index.html[Index]
|
|
|
|
== HttpSession Setup
|
|
|
|
The first step is to integrate Spring Session with the HttpSession. These steps are already outlined in the link:./boot-redis.html[HttpSession with Redis Guide].
|
|
|
|
Please make sure you have already integrated Spring Session with HttpSession before proceeding.
|
|
|
|
// tag::config[]
|
|
|
|
[[websocket-spring-configuration]]
|
|
== Spring Configuration
|
|
|
|
In a typical Spring WebSocket application, you would implement `WebSocketMessageBrokerConfigurer`.
|
|
For example, the configuration might look something like the following:
|
|
|
|
====
|
|
[source,java]
|
|
----
|
|
include::{websocketdoc-test-dir}WebSocketConfig.java[tags=class]
|
|
----
|
|
====
|
|
|
|
We can update our configuration to use Spring Session's WebSocket support.
|
|
The following example shows how to do so:
|
|
|
|
====
|
|
.src/main/java/samples/config/WebSocketConfig.java
|
|
[source,java]
|
|
----
|
|
include::{samples-dir}spring-session-sample-boot-websocket/src/main/java/sample/config/WebSocketConfig.java[tags=class]
|
|
----
|
|
|
|
To hook in the Spring Session support we only need to change two things:
|
|
|
|
<1> Instead of implementing `WebSocketMessageBrokerConfigurer`, we extend `AbstractSessionWebSocketMessageBrokerConfigurer`
|
|
<2> We rename the `registerStompEndpoints` method to `configureStompEndpoints`
|
|
====
|
|
|
|
What does `AbstractSessionWebSocketMessageBrokerConfigurer` do behind the scenes?
|
|
|
|
* `WebSocketConnectHandlerDecoratorFactory` is added as a `WebSocketHandlerDecoratorFactory` to `WebSocketTransportRegistration`.
|
|
This ensures a custom `SessionConnectEvent` is fired that contains the `WebSocketSession`.
|
|
The `WebSocketSession` is necessary to end any WebSocket connections that are still open when a Spring Session is ended.
|
|
* `SessionRepositoryMessageInterceptor` is added as a `HandshakeInterceptor` to every `StompWebSocketEndpointRegistration`.
|
|
This ensures that the `Session` is added to the WebSocket properties to enable updating the last accessed time.
|
|
* `SessionRepositoryMessageInterceptor` is added as a `ChannelInterceptor` to our inbound `ChannelRegistration`.
|
|
This ensures that every time an inbound message is received, that the last accessed time of our Spring Session is updated.
|
|
* `WebSocketRegistryListener` is created as a Spring bean.
|
|
This ensures that we have a mapping of all of the `Session` IDs to the corresponding WebSocket connections.
|
|
By maintaining this mapping, we can close all the WebSocket connections when a Spring Session (HttpSession) is ended.
|
|
|
|
|
|
// end::config[]
|
|
|
|
[[websocket-sample]]
|
|
== `websocket` Sample Application
|
|
|
|
The `websocket` sample application demonstrates how to use Spring Session with WebSockets.
|
|
|
|
=== Running the `websocket` Sample Application
|
|
|
|
You can run the sample by obtaining the {download-url}[source code] and invoking the following command:
|
|
|
|
====
|
|
----
|
|
$ ./gradlew :spring-session-sample-boot-websocket:bootRun
|
|
----
|
|
====
|
|
|
|
[TIP]
|
|
=====
|
|
For the purposes of testing session expiration, you may want to change the session expiration to be 1 minute (the default is 30 minutes) by adding the following configuration property before starting the application:
|
|
|
|
====
|
|
.src/main/resources/application.properties
|
|
----
|
|
server.servlet.session.timeout=1m # Session timeout. If a duration suffix is not specified, seconds will be used.
|
|
----
|
|
====
|
|
=====
|
|
|
|
NOTE: For the sample to work, you must https://redis.io/download[install Redis 2.8+] on localhost and run it with the default port (6379).
|
|
Alternatively, you can update the `RedisConnectionFactory` to point to a Redis server.
|
|
Another option is to use https://www.docker.com/[Docker] to run Redis on localhost.
|
|
See https://hub.docker.com/_/redis/[Docker Redis repository] for detailed instructions.
|
|
|
|
You should now be able to access the application at http://localhost:8080/
|
|
|
|
=== Exploring the `websocket` Sample Application
|
|
|
|
Now you can try using the application. Authenticate with the following information:
|
|
|
|
* *Username* _rob_
|
|
* *Password* _password_
|
|
|
|
Now click the *Login* button. You should now be authenticated as the user **rob**.
|
|
|
|
Open an incognito window and access http://localhost:8080/
|
|
|
|
You are prompted with a login form. Authenticate with the following information:
|
|
|
|
* *Username* _luke_
|
|
* *Password* _password_
|
|
|
|
Now send a message from rob to luke. The message should appear.
|
|
|
|
Wait for two minutes and try sending a message from rob to luke again.
|
|
You can see that the message is no longer sent.
|
|
|
|
[NOTE]
|
|
.Why two minutes?
|
|
====
|
|
Spring Session expires in 60 seconds, but the notification from Redis is not guaranteed to happen within 60 seconds.
|
|
To ensure the socket is closed in a reasonable amount of time, Spring Session runs a background task every minute at 00 seconds that forcibly cleans up any expired sessions.
|
|
This means you need to wait at most two minutes before the WebSocket connection is closed.
|
|
====
|
|
|
|
You can now try accessing http://localhost:8080/
|
|
You are prompted to authenticate again.
|
|
This demonstrates that the session properly expires.
|
|
|
|
Now repeat the same exercise, but instead of waiting two minutes, send a message from each of the users every 30 seconds.
|
|
You can see that the messages continue to be sent.
|
|
Try accessing http://localhost:8080/
|
|
You are not prompted to authenticate again.
|
|
This demonstrates the session is kept alive.
|
|
|
|
NOTE: Only messages sent from a user keep the session alive.
|
|
This is because only messages coming from a user imply user activity.
|
|
Received messages do not imply activity and, thus, do not renew the session expiration.
|