Re: [hybi] About authentication mechanism

[Ian Fette (イアンフェッティ) <[e-mail]>]

On Tue, Jun 21, 2011 at 5:20 PM, Iñaki Baz Castillo <[e-mail]> wrote:

> 2011/6/22 Ian Fette (イアンフェッティ) <[e-mail]>:
> > I would not want to support this from the browser side. We finally are
> > starting to kill in browsers HTTP AUTH dialogs created by subresources
> > (images etc). Frankly it's a very poor user experience. I think most
> people
> > will use WS the way they use XHR + long polling, namely they will be on
> an
> > established page, do their authentication however they do their
> > authentication, set a cookie and move on. In some small corner of the
> > universe, a small set of applications may continue to use HTTP AUTH, but
> I
> > don't feel compelled to go out of the way to make its use any easier than
> if
> > I had requested javascript from another origin which popped up an auth
> > dialog. (Rather, I would probably block that as a browser).
>
> So what about if the websocket server is not the same as the web
> server from which the JS code has been got? Would the WS handshake
> request include a Cookie header (that replied in the HTTP 200 OK from
> the server? so, should the separate websocket server do some magic
> with the Cookie value to verify ist validity?
>

How would you do it if you weren't using WebSockets but instead XHR? I doubt
you would use HTTP auth...


>
> Many web servers store the sessions data in memory so, which kind of
> exotic mechanism should use the separate websocket server to validate
> the given Cookie? use a shared database or shared memory (i.e.
> memcached) for storing sessions?
>
> Honestly I'm a bit afraid about your assumption in which clearly you
> assume that the websocket server listens in the same host as the web
> server.


I'm not assuming they're on the same host. Certainly at Google that would
not be the case.


> I strongly think that the protocol should define a well
> specified and feasible authentication mechanism instead of assuming
> that develovers will do some kind of magic in server side (a protocol
> should not require that).
>
> Regards.
>
> PS: I agree that prompting the user with HTTP authentication dialog is
> a pain, but I'm not suggesting that for websocket. In other thread I
> explained how the JavaScript code retrieved by the browser (after user
> login using whatever mechanism) could containg the WS URI connection
> along with authentication information (i.e. user and pass for Digest
> auth). Then the browser contacts the websocket server (don't assume
> it's co-located with the web server), receives the 401 containing the
> realm and nonce to use, and generates a new WS handshake request with
> proper authentication credentials. This would prompt nothing to the
> user.
>


I agree that a better solution would be to do whatever authentication you
need when the user goes to the website, and then once the user is
authenticated open the WS connection and pass some sort of credential. That
could be via cookies if it's on the same origin, or it could be passed over
the established WS connection. I don't know that it should be defined in the
WS API though, as different sites might want to use vastly different
authentication mechanisms (client-side certs, passwords, oauth, ...). It's
much more flexible to leave it to the application.


>
> --
> Iñaki Baz Castillo
> <[e-mail]>
>