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

["ASF subversion and git services (JIRA)" <ji...@apache.org>]

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

ASF subversion and git services commented on WICKET-6493:
---------------------------------------------------------

Commit d02bc37b0cc555fc6b02f054f94c721cc38be907 in wicket's branch refs/heads/wicket-7.x from [~mgrigorov]
[ https://git-wip-us.apache.org/repos/asf?p=wicket.git;h=d02bc37 ]

WICKET-6483 JavaxUpgradeHttpRequest can cause NullPointerException

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

Revert the change to use 'request.getSession(false) because this breaks WicketTester/WebSocketTester infrastructure

(cherry picked from commit 4b8ac4c8cc14f2926312e2572fee4299256e7b11)


> 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
>             Fix For: 8.0.0, 7.10.0
>
>
> 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)