Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enrich the message for "connected" events with Principal [SPR-12479] #17085

Closed
spring-projects-issues opened this issue Nov 27, 2014 · 5 comments
Assignees
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

Daniel Siviter opened SPR-12479 and commented

When receiving all AbstractSubProtocolEvent events the content of the SessionConnectedEvent differs and appears to be an embedded SessionConnectEvent inside of the SessionConnectedEvent. A simple example using Spring Boot, Security and the simple broker results in the following logging:

2014-11-27 13:44:08.289  INFO 4092 --- [nio-8080-exec-8] civvi.streaming.GreetingController       : Event recieved. [type=SessionConnectEvent,user=org.springframework.security.authentication.UsernamePasswordAuthenticationToken@bbd60c2f: Principal: org.springframework.security.core.userdetails.User@36ebcb: Username: user; Password: [PROTECTED]; Enabled: true; AccountNonExpired: true; credentialsNonExpired: true; AccountNonLocked: true; Granted Authorities: ROLE_USER; Credentials: [PROTECTED]; Authenticated: true; Details: org.springframework.security.web.authentication.WebAuthenticationDetails@fffde5d4: RemoteIpAddress: 0:0:0:0:0:0:0:1; SessionId: 3F80B97FD34A55597672915DFCDA1B57; Granted Authorities: ROLE_USER,session=jnsg2kr_]
2014-11-27 13:45:19.887  INFO 4092 --- [boundChannel-20] civvi.streaming.GreetingController       : Event recieved. [type=SessionConnectedEvent,user=null,session=jnsg2kr_]

When attempting to access the user it's not possible without working around the embedded event. The logging code I'm using is as follows:

LOG.info("Event recieved. [type={},user={},session={}]",
				e.getClass().getSimpleName(),
				StompHeaderAccessor.getUser(e.getMessage().getHeaders()),
				StompHeaderAccessor.getSessionId(e.getMessage().getHeaders()));

Inspection of the data reveals the following structure:

SessionConnectedEvent {
  message = GenericMessage {
    headers = HashMap {
      simpConnectMessage = GenericMessage {
        headers = HashMap {
          simpUser = UsernamePasswordAuthenticationToken {
            ...
          },
          ...
        },
        ...
      },
      simpUser = *null*,
      ...
    },
    ...
  }
}

From stack trace:

Thread [clientOutboundChannel-26] (Suspended (breakpoint at line 61 in GreetingController))	
	GreetingController.onApplicationEvent(AbstractSubProtocolEvent) line: 61	
	GreetingController.onApplicationEvent(ApplicationEvent) line: 1	
	SimpleApplicationEventMulticaster.invokeListener(ApplicationListener, ApplicationEvent) line: 151	
	SimpleApplicationEventMulticaster.multicastEvent(ApplicationEvent) line: 128	
	AnnotationConfigEmbeddedWebApplicationContext(AbstractApplicationContext).publishEvent(ApplicationEvent) line: 331	
	StompSubProtocolHandler.publishEvent(ApplicationEvent) line: 299	
	StompSubProtocolHandler.handleMessageToClient(WebSocketSession, Message<?>) line: 349	
	SubProtocolWebSocketHandler.handleMessage(Message<?>) line: 337	
	ExecutorSubscribableChannel$SendTask.run() line: 135	
	ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker) line: 1142	
	ThreadPoolExecutor$Worker.run() line: 617	
	Thread.run() line: 745	

Affects: 4.1.2

@spring-projects-issues
Copy link
Collaborator Author

Daniel Siviter commented

If this is expected functionality then please document as it's rather unclear.

@spring-projects-issues
Copy link
Collaborator Author

Rossen Stoyanchev commented

This is indeed expected behavior. The SimpleBrokerMessageHandler is not explicitly aware of STOMP details so when a client connects, instead of sending a STOMP CONNECTED frame back, it responds with an "ack" message which also has the CONNECT message being acknowledged embedded as a header (this is in the handleInternalMessage method). This allows the StompSubProtocolHandler to prepare the STOMP CONNECTED frame headers (this is in the getStompHeaderAccessor method). In terms of documenting this, what information where you looking to obtain from the SessionConnectedEvent?

@spring-projects-issues
Copy link
Collaborator Author

Daniel Siviter commented

The biggest issue I've found is when implementing some level of monitoring. When using spring-security the user Principle is added to the message, but that is now embedded further inside a complex set of Maps and is by no means clear. It involved debugging the server and stepping through the code for something I'd expect to be easily available, especially using the convenience method SimpMessageHeaderAccessor#getUser(...) which doesn't work in this case.

@spring-projects-issues
Copy link
Collaborator Author

Rossen Stoyanchev commented

Thanks for the feedback. There is actually not much in an actual STOMP CONNECTED frame that would be of help. That said we can certainly ensure the Spring Message representing a CONNECTED frame contains the Principal. This is what I've done with commit fa89ae.

@spring-projects-issues
Copy link
Collaborator Author

Rossen Stoyanchev commented

Modified title (was: "SessionConnectedEvent content differs to other events").

@spring-projects-issues spring-projects-issues added type: enhancement A general enhancement in: web Issues in web modules (web, webmvc, webflux, websocket) labels Jan 11, 2019
@spring-projects-issues spring-projects-issues added this to the 4.1.3 milestone Jan 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants