[jira] [Commented] (WICKET-6493) WebSocket SessionIds are wrong (HttpSession one used instead of Websocket one) + NPE if no HttpSession is found during Handshake Request

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

    [ https://issues.apache.org/jira/browse/WICKET-6493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16247354#comment-16247354 ] 

Martin Grigorov commented on WICKET-6493:
-----------------------------------------

Thank you for the ticket!

Wicket uses the HttpSession id because this is what the page storages use, see IPageStore and IDataStore interfaces.
The WebSocket registry uses the applicationName, the sessionId and the pageId to be able to lookup the WebSocket connection for a page and the page itself from the stores so that the applications can update Wicket Components with IPartialPageUpdateTarget#add(Component...) API, just like AjaxRequestTarget does.

Wicket's Ajax and WebSocket support are implemented with stateful Behaviors.
Since Wicket 7.4.0 it is possible to make any Ajax behavior stateless but then some functionalities are no more possible/guaranteed. 
If the HttpSession id is not used then you won't be able to update Wicket components the way you are used to. You will be only able to use the standard send(String) and send(byte[]) WebSocket methods.

> WebSocket SessionIds are wrong (HttpSession one used instead of Websocket one) + NPE if no HttpSession is found during Handshake Request
> ----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WICKET-6493
>                 URL: https://issues.apache.org/jira/browse/WICKET-6493
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket-native-websocket
>    Affects Versions: 7.7.0
>         Environment: Linux, JDK 8, Jetty 9
>            Reporter: Torsten Krah
>            Assignee: Martin Grigorov
>
> Reading the *HandshakeRequest* javadoc this is written:
> {code}
>     /**
>      * Return a reference to the HttpSession that the web socket handshake that 
>      * started this conversation was part of, if the implementation
>      * is part of a Java EE web container.
>      *
>      * @return the http session or {@code null} if either the websocket
>      * implementation is not part of a Java EE web container, or there is
>      * no HttpSession associated with the opening handshake request.
>      */
>     Object getHttpSession();
> {code}
> So its valid to have *NO* *HttpSession* assigned to a JSR356 request.
> But Wicket seems to "expect" this because in *JavaxUpgradeHttpRequest* the HttpSession is extracted from the *userProperties* which is not there, if it was "null" in the HandshakeRequest.
> In the processing the chain will reach the *AbstractWebSocketProcessor* constructor which calls
> {code}
> this.sessionId = request.getSession(true).getId();
> {code}
> which is going to fail here because there is no HttpSession on the crafted request used here.
> I wonder why the *sessionId* is taken from the HttpSession at all - shouldn't it be the JSR356 session id which you can get with *session.getId()*.
> If you look e.g. at the *IWebSocketConnectionRegistry* javadocs most methods have their *sessionId* argument documented with:
> {code}
> 	 * @param sessionId
> 	 *      the web socket client session id
> {code}
> but actually the HttpSession id is used instead of the WebSocket sessionId - which is a totally different one.
> So i am proposing to use the "real" websocket session id here taken from the constructor call:
> {code}
> public JavaxWebSocketProcessor(JavaxUpgradeHttpRequest request, final Session session, final WebApplication application, EndpointConfig endpointConfig)
> {code}
> where there is the *session* argument where *session.getId()* actually returns the websocket session id which can last longer and is 100% there - the HttpSession must not be there at all as written.
> Unfortunately the javadoc on *IWebSocketConnectionRegistry* for
> {code}
> 	/**
> 	 * @param application
> 	 *            the web application to look in
> 	 * @param sessionId
> 	 * @return collection of web socket connection used by a client with the given session id
> 	 */
> 	Collection<IWebSocketConnection> getConnections(Application application, String sessionId);
> {code}
> does not state which "sessionId" is meant here - i guess its the *HttpSession* - in that case please clarify the JavaDocs here.
> The code maybe need to "track"the HttpSession id to handle that usecase - but in an optional way because it may not be there.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)