On 08/11/2012 02:02, Danny Coward wrote:
> On 11/3/12 4:36 AM, Mark Thomas wrote:
>> On 02/11/2012 23:59, Danny Coward wrote:
>>> Hi Greg,
>>>
>>> On 11/1/12 3:05 PM, Greg Wilkins wrote:
>>>> We've bumped against this problem, but not really found a solution nor
>>>> found it a total show stopper.
>>>>
>>>> Without browser support, there is no way to refresh the cookie on the
>>>> client side. So to keep a HTTP session active, either the application
>>>> has to arrange for an occasional HTTP request, or even to occasionally
>>>> drop the websocket connection and force a rehandshake.
>>>>
>>>> Unless we advocate for a setCookie frame we can send over websocket, I
>>>> think the only solution is to simply say that the HTTPSession is
>>>> unrelated to the Websocket connection.
>>> Well, they are clearly related at the time of the opening handshake. So
>>> I think we can depend on getting the user's identity context used to
>>> initiate a web socket connection, for example. And I think we should
>>> require that if the user invalidates the session (e.g. by logging out)
>>> we should close any web socket connections that were initiated under
>>> that session.
>>>
>>> But, yes :( What it looks like we may not be able to do is to require
>>> the http session be kept alive if only the web sockets in a web
>>> application are active if there are no http requests. I think we should
>>> probably let containers do this if they have some informal strategy to
>>> do it, but not require it.
>>>
>>> OK with everyone ?
>> Not really. This assumes that the WebSocket needs the user's identity.
>> I'd prefer that the application added an HttpSessionListener and used
>> that to close the WebSocket connection if it wanted to when the HTTP
>> session ended. We could probably provide most of the plumbing for this
>> in the spec so all that app had to do was a single call to associate the
>> WebSocket connection with an HttpSession.
>
> OK, perhaps I'm confusing separate cases. Please check my thinking...
>
> The association we're trying to qualify is between the HttpSession at
> the time of the opening handshake and the websocket session.
Agreed. And that relationship is application specific. Just because
there is an HttpSession available when a web socket connection is
created does not mean that the the two have to be associated. I agree
that they probably will be but I think it is wrong to require that they
are associated. The developer should have the choice whether or not to
associated them.
> the websocket is protected by a security constraint, and the user logs out
> - in this case, I think the implementations have to close the web socket
> connection at the time that the HttpSession in invalidated
This assumes that an HttpSession is required when a security constraint
is present. That is only the case for FORM authentication. It is not the
case for BASIC, DIGEST or CLIENT-CERT.
Further, logout is really only something that makes sense when FORM auth
is used. It doesn't work for the others. For BASIC, DIGEST and
CLIENT-CERT, the browser will simply resend the credentials on the next
request for a protected resource.
> the websocket is not protected by a security constraint, and the user
> logs out
> - in this case, I was thinking we should also close the web socket
> connection, but Mark you think we should let the developer make that
> choice ?
>
> the websocket is active, and the HttpSession is about to time out
> - if the websocket is still active we'd like to touch the http session
> to keep it alive, but we cannot do that because we'd need to alter the
> client cookie expiration time.
> - so, if the websocket is protected by a security constraint, we need to
> close it
> - if the web socket is not protected by a security constraint, then let
> the developer choose ?
There are multiple factors here:
- is an HttpSession present (Yes/No)
- is the WebSocket endpoint protected by a security constraint (Yes/No)
- what authentication mechanism is in use (BASIC/DIGEST/FORM/
CLIENT-CERT/CONTAINER-SPECIFIC)
- logout / session expiration
That gives us at least 32 (actually a few won't work but ignoring that
for now) combinations plus an additional 8 for each container specific
authentication mechanism.
We either need to be clear about what happens in each of the above cases
or provide the hooks to enable the developer to make the choice (with
some sensible defaults). I prefer the latter option.
Mark