On 12/7/12 9:43 AM, Mark Thomas wrote:
" type="cite">I think it would be convenient to do so. Its the same Principal that is available on the OpeningHandshake. But perhaps developers would like to access it even if they don't intercept the handshake. Like POJO developers.On 07/12/2012 00:56, Danny Coward 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.Do we want to expose this through the API?
" type="cite">3) 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.Can we make this behaviour optional?
My thinking is that if the server has revoked the access of a user to a certain resource, if that resource is one of our websockets, we should close it. What would be the reason to keep a protected resource like this available to a client after such a time ?
[jsr356-experts] Re: [jsr356-users] Re: Summary: relationship of WebSocket Session/HttpSession/Identity/web logout