You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Martin Grigorov (JIRA)" <ji...@apache.org> on 2017/11/10 12:19:00 UTC
[jira] [Comment Edited] (WICKET-6493) WebSocket SessionIds are
wrong (HttpSession one used instead of Websocket one) + NPE if no
HttpSession is found during Handshake Request
[ https://issues.apache.org/jira/browse/WICKET-6493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16247409#comment-16247409 ]
Martin Grigorov edited comment on WICKET-6493 at 11/10/17 12:18 PM:
--------------------------------------------------------------------
Which javadoc exactly you mean ?
HandshakeRequest is not part of Wicket.
How do you get to the NPE ?
By adding WebSocketBehavior to your Page a new HttpSession should be created if there is no bound one already.
In what cases the handshake request comes without http session for the current user ?
was (Author: mgrigorov):
Which javadoc exactly you mean ?
HandshakeRequest is not part of Wicket.
How do you get to the NPE ?
By adding WebSocketBehavior to your Page a new HttpSession should be created if there is no bound one already.
In what cases the handshake requests without http session for the current user ?
> 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)