Skip to main content

[jsr356-users] Re: [jsr356-experts] Summary: relationship of WebSocket Session/HttpSession/Identity/web logout

  • From: Danny Coward < >
  • To:
  • Cc: Joakim Erdfelt < >, Greg Wilkins < >
  • Subject: [jsr356-users] Re: [jsr356-experts] Summary: relationship of WebSocket Session/HttpSession/Identity/web logout
  • Date: Thu, 06 Dec 2012 18:22:38 -0800

Hey Joakim,

On 12/6/12 6:03 PM, Joakim Erdfelt wrote:
" type="cite">
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?
Actually I'm not proposing the HttpSession be kept alive. Just that it be available at the time of the opening handshake.

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.

" type="cite">
Also what is the role of HttpSession.getLastAccessedTime() for implementations of this JSR?
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.
" type="cite">
Is the JSR going to dictate that implementations keep HttpSession alive and current based on activity on the WebSocket?
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.
" type="cite">
Should implementations of the JSR do anything special if the HttpSession is invalidated (by for example different Servlet that calls HttpSession.invalidate())? 
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.

" type="cite">
Example reaction would be to force an automatic close (status code 1001, Going Away/Shutdown) of the server websocket if the HttpSession is invalidated.
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.

Does that make sense ?

- Danny

" type="cite">


On Thu, Dec 6, 2012 at 5:56 PM, Danny Coward < " target="_blank"> > 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




--
Danny Coward
Java EE
Oracle Corporation



--
Danny Coward
Java EE
Oracle Corporation


[jsr356-users] [jsr356-experts] Summary: relationship of WebSocket Session/HttpSession/Identity/web logout

Danny Coward 12/07/2012

[jsr356-users] Re: [jsr356-experts] Summary: relationship of WebSocket Session/HttpSession/Identity/web logout

Joakim Erdfelt 12/07/2012

[jsr356-users] Re: [jsr356-experts] Summary: relationship of WebSocket Session/HttpSession/Identity/web logout

Danny Coward 12/07/2012

[jsr356-users] [jsr356-experts] Re: Summary: relationship of WebSocket Session/HttpSession/Identity/web logout

Mark Thomas 12/07/2012

[jsr356-users] [jsr356-experts] Re: Re: Summary: relationship of WebSocket Session/HttpSession/Identity/web logout

Danny Coward 12/07/2012

[jsr356-users] [jsr356-experts] Re: Re: Summary: relationship of WebSocket Session/HttpSession/Identity/web logout

Mark Thomas 12/08/2012

[jsr356-users] [jsr356-experts] Re: Summary: relationship of WebSocket Session/HttpSession/Identity/web logout

Danny Coward 12/11/2012

[jsr356-users] [jsr356-experts] Re: Summary: relationship of WebSocket Session/HttpSession/Identity/web logout

Mark Thomas 12/12/2012
 
 
Close
loading
Please Confirm
Close