[jira] [Updated] (WICKET-5627) broadcastMessage(): hook to set more thread-local context before rendering components

["Andrei Badea (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-5627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrei Badea updated WICKET-5627:
---------------------------------

    Description: 
Our application uses Spring Security for authentication and authorization. We want to push rendered components to clients via WebSocketRequestHandler.add().

The problem we are hitting is that (at least) the component rendering needs to take place in the (Spring Security) context of the user to whom the component "belongs". Effectively, next to the ThreadContext.set... calls in AbstractWebSocketProcessor.broadcastMessage(), we would like to call SecurityContextHolder.setContext(). To do that, we would need some sort of hook that is invoked before sendPayload() is called.

I am happy to provide a patch, but would rather discuss the approach first. For instance, if this hook is simply an overridable method such as AWSP.broadcastMessageToPage() in the attached proof of concept, it would be fairly invasive to use from the Wicket user's perspective. The user would have to:

* subclass the respective AbstractWebSocketProcessor server-specific subclass
* subclass the respective server-specific web filter
* in the filter, override a (newly introduced) newWebSocketProcessor() method to return the custom AbstractWebSocketProcessor subclass

Do you see a better way, or perhaps more in line with the direction you want to take Wicket's WebSocket API?


  was:
Our application uses Spring Security for authentication and authorization. We want to push rendered components to clients via WebSocketRequestHandler.add().

The problem we are hitting is that (at least) the component rendering needs to take place in the (Spring Security) context of the user to whom the component "belongs". Effectively, next to the ThreadContext.set... calls in broadcastMessage(), we would like to call SecurityContextHolder.setContext(). To do that, we would need some sort of hook that is invoked before sendPayload() is called.

I am happy to provide a patch, but would rather discuss the approach first. For instance, if this hook is simply an overridable method such as AbstractWebSocketProcessor.broadcastMessageToPage() as per the attached proof of concept, it would be fairly invasive to use from the Wicket user's perspective. The user would have to:

* subclass the respective AbstractWebSocketProcessor server-specific subclass
* subclass the respective server-specific web filter
* in the filter, override a (newly introduced) newWebSocketProcessor() method to return the custom AbstractWebSocketProcessor subclass

Do you see a better way, or perhaps more in line with the direction you want to take Wicket's WebSocket API?



> broadcastMessage(): hook to set more thread-local context before rendering components
> -------------------------------------------------------------------------------------
>
>                 Key: WICKET-5627
>                 URL: https://issues.apache.org/jira/browse/WICKET-5627
>             Project: Wicket
>          Issue Type: Improvement
>          Components: wicket-native-websocket
>    Affects Versions: 6.16.0
>            Reporter: Andrei Badea
>            Assignee: Martin Grigorov
>
> Our application uses Spring Security for authentication and authorization. We want to push rendered components to clients via WebSocketRequestHandler.add().
> The problem we are hitting is that (at least) the component rendering needs to take place in the (Spring Security) context of the user to whom the component "belongs". Effectively, next to the ThreadContext.set... calls in AbstractWebSocketProcessor.broadcastMessage(), we would like to call SecurityContextHolder.setContext(). To do that, we would need some sort of hook that is invoked before sendPayload() is called.
> I am happy to provide a patch, but would rather discuss the approach first. For instance, if this hook is simply an overridable method such as AWSP.broadcastMessageToPage() in the attached proof of concept, it would be fairly invasive to use from the Wicket user's perspective. The user would have to:
> * subclass the respective AbstractWebSocketProcessor server-specific subclass
> * subclass the respective server-specific web filter
> * in the filter, override a (newly introduced) newWebSocketProcessor() method to return the custom AbstractWebSocketProcessor subclass
> Do you see a better way, or perhaps more in line with the direction you want to take Wicket's WebSocket API?



--
This message was sent by Atlassian JIRA
(v6.2#6252)