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

["Martin Grigorov (JIRA)" <ji...@apache.org>]

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

Martin Grigorov resolved WICKET-5627.
-------------------------------------

       Resolution: Fixed
    Fix Version/s: 6.17.0
                   7.0.0-M3

Implemented with https://git-wip-us.apache.org/repos/asf?p=wicket.git;a=commitdiff;h=e877ae21;hp=35f2003a456fb0fcd6f62b586565efafa4f3e111
Use the test case for inspiration for your use case.

Thanks!

> 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
>             Fix For: 7.0.0-M3, 6.17.0
>
>         Attachments: proof-of-concept.diff
>
>
> 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)