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.
> 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?
> 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.
Mark