On 15/11/2012 01:58, Danny Coward wrote:
> On 11/14/12 2:27 AM, Mark Thomas wrote:
<snip/>
>> For BASIC/DIGEST/CLIENT-CERT auth the browser essentially caches the
>> credentials so the user is authenticated for all practical purposes
>> until they close the browser regardless of what happens with the
>> session. That will also close any WebSocket connection. In these cases
>> there is nothing for us to do.
> Yes...although there is nothing to prevent a browser (add-on) from
> clearing the credential cache (without clearing the cookies) at the whim
> of the user. Then if the user logs in as someone else, they get the same
> session, new user identity, and websockets still running that were
> created with the old user identity. So I guess it's only a happy
> coincidence that browsers generally clear both the credential cache and
> close web sockets at the same time.
It could be by design rather than co-incidence but I don't recall seeing
any of this anywhere in any specification.
The concept of logout has always been rather ill-defined and that is the
root cause of what we are hitting here.
>> For FORM the user is authenticated until the session expires. This is a
>> tricky one as there is no easy way for the WebSocket implementation to do:
>> if (url.isProtected() && auth == AuthMethod.FORM) {
>> // Associate WebSocket connection with Session
>> ...
>> }
>> Being able to do that would require placing some additional requirements
>> on the Servlet Spec.
> It looks like we could determine the auth method from the
> HttpServletRequest, and check the user principal is non-null. Then I
> think we would know definitively that we are working within an
> HttpSession on which a FORM authentication hangs ?
The complication is pre-emptive authentication. On further reflection
I'm leaning towards the simple approach you suggest above. Behaviour
with pre-emptive authentication would be container specific but would
still follow the process set out below.
> I think we are struggling with the basic problem that the web socket
> frames do not (natively) carry either user identity or session
> information.
Agreed. With lack of well-defined logout for all authentication
mechanisms compounding the issue.
>>> and we can recommend developers use an HttpSessionListener to track the
>>> session to establish whatever relationship they want with it over its
>>> lifetime.
>> +1. I suggest we provide a implementation of that listener that they can
>> start from.
> what are you thinking the WebSocketHttpSessionListener would do ?
>
> In my mind, the main question they'd need to ask would be 'what is the
> HttpSession that was in place when this WebSocket session was started ?'
> which is answered by the existing Session.getHttpSession()
My thoughts are along the following lines:
If the following are all true when the WebSocket connection is established:
- an HTTP session is present
- HttpServletRequest.getAuthType() != null
- HttpServletRequest.getUserPrincipal() != null
By default add a listener to the session that closes the WebSocket
connection (if still open) when the session is destroyed.
The user would have the option (mechanism TBD) not to have this listener
added to the current HTTP session.
Mark