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