Re: [hybi] About authentication mechanism

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

On Wed, Jun 22, 2011 at 3:06 AM, Iñaki Baz Castillo <[e-mail]> wrote:

> 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.
>
>
>
XHR can be sent to a different origin. http://www.w3.org/TR/cors/


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

A desktop widget / android app / ... surely already faces this problem with
whatever communication mechanism they use, and I would be frankly amazed if
they expected to solve it with http auth...


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