Re: [hybi] About authentication mechanism

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

2011/6/22 Ian Fette (イアンフェッティ) <[e-mail]>:
>> 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...

Usually XHR is sent to the same web server (so using Cookie is very
suitable), am I wrong?
Note however I'm not an expert in XHR so maybe I miss something.



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

Ok, but take into account that not all the WS connections would be
preceded by an access to a web page. Let's imagine a desktop wigdet
(or an Android app!) that directly open a WS connection (without
opening first a web page, so the client cannot authenticate via an
HTML form in "any custom way"). What to do then? How to prompt the
user for credentials? which authentication mechanism to use? So there
would be needed:

- An API for promting the user for credentials.
- A specified authentication mechanism for "pure websocket" connection
(without depending on a previous HTTP/HTML access).

Have the WG considered this case?


IMHO authentication should occur at protocol level, rather than at
application level. This is true in all the protocols of Internet but
HTTP, which is a jungle. But HTTP usually means displaying a web page
with some HTML form in which the user can interact by setting his
credentials, press "submit" and that's all. Such kind of
authentication level is not possible in WebSocket as a WebSocket
renders nothing to the user, a WebSocket server does reply a web page.

I still see the need to mandate the support of HTTP Digest
authentication in WebSocket (which involves an API and a section in
current specification.

Regards.




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