Re: [hybi] About authentication mechanism

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

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?

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 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ñaki Baz Castillo
<[e-mail]>