[NODE-199] Setup WebSocket STOMP CSRF exception thrown when SolarNode restarted Created: 27/May/21  Updated: 20/Jan/23  Resolved: 24/Mar/22

Status: Closed
Project: SolarNode
Component/s: Setup
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Matt Magoffin Assignee: Matt Magoffin
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

If a browser has opened up the SolarNode GUI and has connected to the available WebSocket for STOMP messages, if SolarNode is restarted, when it comes back online the browser will attempt to re-connect to the WebSocket but use an outdated CSRF token, resulting in alarming-looking ERROR messages in the logs, like this:

2021-05-26 15:18:12 ERROR StompSubProtocolHandler; Failed to send client message to application via MessageChannel in session 15. Sending STOMP ERROR to client.
org.springframework.messaging.MessageDeliveryException: Failed to send message to ExecutorSubscribableChannel[clientInboundChannel]; nested exception is org.springframework.security.web.csrf.InvalidCsrfTokenException: Invalid CSRF Token 'abf7e0d2-dcc2-4de5-b300-8aefe3b9064e' was found on the request parameter '_csrf' or header 'X-CSRF-TOKEN'., failedMessage=GenericMessage [payload=byte[0], headers={simpMessageType=CONNECT, stompCommand=CONNECT, nativeHeaders={X-CSRF-TOKEN=[abf7e0d2-dcc2-4de5-b300-8aefe3b9064e], accept-version=[1.1,1.0], heart-beat=[10000,10000]}, simpSessionAttributes={org.springframework.security.web.csrf.CsrfToken=org.springframework.security.web.csrf.DefaultCsrfToken@1e8f573}, simpHeartbeat=[J@498b85, simpSessionId=15}]
	at org.springframework.messaging.support.AbstractMessageChannel.send(AbstractMessageChannel.java:127)
	at org.springframework.messaging.support.AbstractMessageChannel.send(AbstractMessageChannel.java:104)
	at org.springframework.web.socket.messaging.StompSubProtocolHandler.handleMessageFromClient(StompSubProtocolHandler.java:299)
	at org.springframework.web.socket.messaging.SubProtocolWebSocketHandler.handleMessage(SubProtocolWebSocketHandler.java:309)
	at org.springframework.web.socket.handler.WebSocketHandlerDecorator.handleMessage(WebSocketHandlerDecorator.java:75)
	at org.springframework.web.socket.handler.LoggingWebSocketHandlerDecorator.handleMessage(LoggingWebSocketHandlerDecorator.java:56)
	at org.springframework.web.socket.handler.ExceptionWebSocketHandlerDecorator.handleMessage(ExceptionWebSocketHandlerDecorator.java:58)
	at org.springframework.web.socket.adapter.standard.StandardWebSocketHandlerAdapter.handleTextMessage(StandardWebSocketHandlerAdapter.java:110)
	at org.springframework.web.socket.adapter.standard.StandardWebSocketHandlerAdapter.access$000(StandardWebSocketHandlerAdapter.java:42)
	at org.springframework.web.socket.adapter.standard.StandardWebSocketHandlerAdapter$3.onMessage(StandardWebSocketHandlerAdapter.java:81)
	at org.springframework.web.socket.adapter.standard.StandardWebSocketHandlerAdapter$3.onMessage(StandardWebSocketHandlerAdapter.java:78)
	at org.apache.tomcat.websocket.WsFrameBase.sendMessageText(WsFrameBase.java:394)
	at org.apache.tomcat.websocket.server.WsFrameServer.sendMessageText(WsFrameServer.java:119)
	at org.apache.tomcat.websocket.WsFrameBase.processDataText(WsFrameBase.java:495)
	at org.apache.tomcat.websocket.WsFrameBase.processData(WsFrameBase.java:294)
	at org.apache.tomcat.websocket.WsFrameBase.processInputBuffer(WsFrameBase.java:133)
	at org.apache.tomcat.websocket.server.WsFrameServer.onDataAvailable(WsFrameServer.java:82)
	at org.apache.tomcat.websocket.server.WsFrameServer.doOnDataAvailable(WsFrameServer.java:171)
	at org.apache.tomcat.websocket.server.WsFrameServer.notifyDataAvailable(WsFrameServer.java:151)
	at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.upgradeDispatch(WsHttpUpgradeHandler.java:148)
	at org.apache.coyote.http11.upgrade.UpgradeProcessorInternal.dispatch(UpgradeProcessorInternal.java:54)

A simple refresh of the browser window will eliminate the problem. This ticket is to make a change so the browser refreshes the CSRF token it has cached, both in case of a WebSocket error like this and just periodically as it changes regularly.



 Comments   
Comment by Matt Magoffin [ 24/Mar/22 ]

Some mitigation for this is now in place. The exception can happen still, but is caught by the browser and the updated CSRF token updated for future requests.

Generated at Wed Jun 25 17:15:29 NZST 2025 using Jira 10.3.6#10030006-sha1:0dc21a711362757421d62af2e50bcb9585207f88.