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
--
Greg Wilkins <gregw_at_intalio.com>
http://www.webtide.com
Developer advice and support from the Jetty & CometD experts.