On 12/6/12 6:03 PM, Joakim Erdfelt wrote:
Actually I'm not proposing the HttpSession be kept alive. Just that
it be available at the time of the opening handshake.
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?
I am proposing the Principal established at opening handshake be
available to the websocket session for as long as the Principal is
still authorized for the websocket.
This means as far as the JSR is concerned, the HttpSession is only
marked active when an Http request is made (at the opening
handshake), not when websocket messages go back and forth.
We thought it might at one point, but have moved away from that
idea, because we don't think it could be implemented without
changing the expiry date on cookies in the client, which, obviously,
we cannot do from the server.
Is the JSR going to dictate that implementations keep
HttpSession alive and current based on activity on the
It depends. What I think needs to happen is that if the server
decides the Principal is no longer authorized, the websocket, if it
is protected, should be closed. If that situation is somehow caused
because of HttpSession.invalidate being called, then that is how
those two things might be related in an implementation.
Should implementations of the JSR do anything special if the
HttpSession is invalidated (by for example different Servlet
that calls HttpSession.invalidate())?
I think the expert group discussion seemed to be saying that the
relationship between HttpSession invalidate and the Principal no
longer being valid is not a clear one in all implementations and
modes of authentication. So I'm trying to craft the spec in terms of
the validity of the Principal, not the HttpSession.
Example reaction would be to force an automatic close (status
code 1001, Going Away/Shutdown) of the server websocket if the
HttpSession is invalidated.
Does that make sense ?
On Thu, Dec 6, 2012 at 5:56 PM, Danny
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
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
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
(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 ?
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
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
Or maybe we do want to validate the identity on every message and just
warn users that constraint protected messages can be very expensive?
|| Danny Coward