On 12/7/12 9:43 AM, Mark Thomas wrote:
> 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?
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.
>
>> 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?
Hi Mark,
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 ?
- Danny
>
> Mark
>
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation