Hi Mark,
Thanks for your comments - pls see inline.
On 9/13/12 12:12 PM, Mark Thomas wrote:
> On 08/09/2012 00:08, Danny Coward wrote:
>> If however, the user is not already authenticated, and the client sends
>> a web socket opening handshake for "/foo", then (to my knowledge) there
>> is no way to force an authentication at this point: neither does the web
>> socket spec define an authentication sequence within the handshake, nor
>> do the browsers allow a websocket handshake response to cause a redirect
>> to an http authentication dialog or page (please check my understanding
>> on that last point).
> Confirmed. Both Firefox and Chrome just close the connection when a 401
> is received in response to a WS connection request.
ok thanks.
>> So we can apply the web container security model to protect web socket
>> endpoints and give fine grained control to users, but we are reliant on
>> the users to be pre-authenticated from a prior interaction with a
>> servlet/JSP/static *ML page for it to work.
>>
>> In terms of where to make the configuration of authorization: it looks
>> reasonable to offer web socket developers the options of either doing so
>> in the web.xml in which their web socket endpoints are packaged, or by
>> using the servlet-defined annotations in their code (primarily
>> HttpConstraint).
> That works for me.
>
>> 2) a web socket endpoint can be deployed in the web container so that it
>> can only be accessed using a secure protocol i.e.wss:// only.
>>
>> Here it looks like we could re-use the web container's concept of
>> transport-guarantee. Either offering developers the option of specifying
>> a transport guarantee on the URL to which the web socket endpoint is
>> mapped in the web.xml.
> or ...? There is an "Either..." above but no "... or ...". Are you
> thinking annotations again?
Sorry, yes was thinking to configure some of this in the annotations.
The attributes it seems we need for an endpoint are modeled in part by
the servlet-defined @HttpConstraint, save for the definition of
authentication scheme.
>> Finally, and we already touched on this, once the web application is in
>> use by a number of users, I think we need to following to be true:-
>>
>> 3) HttpSessions and active web sockets
>>
>> a) we need to close web socket connections that are only for use by
>> authenticated users if the user explicitly logs out
>> (HttpSession.invalidate())
>> b) we need to be able to cause the HttpSession to stay alive even even
>> if the user makes no http requests for longer than the allocated
>> timeout. This is for the case when the user is busily using web sockets
>> by not reloading any of the http content.
>>
>> I know how we can do a). I can't think of a great way of doing b) just
>> with the servlet API as it is today.
> Agreed. We need a change in the Servlet API to enable us to "touch" a
> session. Without that, we'll be relying on container specific code which
> will mean implementations have to be part of the container and can't be
> packaged in a web app.
OK I've asked Shing Wai for suggestions on this.
- Danny
> Mark
>
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation