[
https://issues.apache.org/jira/browse/WICKET-6493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Grigorov updated WICKET-6493:
------------------------------------
Fix Version/s: (was: 7.10.0)
(was: 8.0.0)
8.0.0-M9
> 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
> Priority: Major
> Fix For: 8.0.0-M9
>
>
> 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
(v7.6.3#76005)
