From the point of view of a long-lived websocket on the server side, can we
expect these objects to always be valid?
Are implementations expected to ensure that access to HttpSession will
always work?
In other words, keeping the HttpSession alive/valid/unexpired/active, along
with any Principals associated with it?
Also what is the role of
HttpSession.getLastAccessedTime()<
http://docs.oracle.com/javaee/5/api/javax/servlet/http/HttpSession.html#getLastAccessedTime()>for
implementations of this JSR?
Is the JSR going to dictate that implementations keep HttpSession alive and
current based on activity on the WebSocket?
Should implementations of the JSR do anything special if the HttpSession is
invalidated (by for example different Servlet that calls
HttpSession.invalidate())?
Example reaction would be to force an automatic close (status code 1001,
Going Away/Shutdown) of the server websocket if the HttpSession is
invalidated.
--
Joakim Erdfelt <joakim_at_intalio.com>
On Thu, Dec 6, 2012 at 5:56 PM, Danny Coward <danny.coward_at_oracle.com>wrote:
> OK, so in the spirit of trying to close out this discussion and find
> what is reasonable to require in the specification, what it looks like to
> me we are left with is this:-
>
> 1) The only association between websocket session and HttpSession is at
> opening handshake time. The API gives developers a convenient access to the
> HttpSession object at that point in time.
> 2) The user identity associated with the websocket Session is the user
> identity that was established at the opening handshake.
> 2) If the server decides that authorization for this websocket resource by
> this user identity has ended (it expired, or some logout mechanism was
> invoked) then the websocket implementation must immediately close the
> connection.
>
> (from my read of the websocket spec, the most suitable close code for the
> latter is 1008).
>
> Is there anything else that we need to specify ?
>
> Thanks,
>
> - Danny
>
>
>
> On 11/28/12 11:49 PM, Greg Wilkins wrote:
>
> Unfortunately even form authentication does not have the same
> lifecycle as HTTP Session.
>
> Sure if the HTTPSession is invalidated then then a form Auth user is
> logged out. But a users authentication/authorization can be revoked
> during the life of a HttpSession (eg their credit expires in some
> central JAAS server). For that reason Form auth will often store the
> credentials in the session and revalidate them on every request.
> Basic/Digest authentication revalidate on each request by their
> nature.
>
> I really don't think we want to get into that situation for websocket,
> as it could be a considerable burden to validate credentials on every
> message received before calling any handlers. If we don't validate
> on every message, then we are essentially saying that the identity
> associated with every message is the identity as it was established
> during the handshake - in which case I don't think we should be
> associating with the HTTPsession (unless the application does so
> explicitly).
>
> Or maybe we do want to validate the identity on every message and just
> warn users that constraint protected messages can be very expensive?
>
> cheers
>
>
>
>
>
> --
> <http://www.oracle.com> * Danny Coward *
> Java EE
> Oracle Corporation
>