Re: [hybi] About authentication mechanism

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

Speaking as an individual,

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

-Ian

On Tue, Jun 21, 2011 at 4:35 PM, Greg Wilkins <[e-mail]> wrote:

> On 21 June 2011 23:43, Iñaki Baz Castillo <[e-mail]> wrote:
> > Hi, any comment about this please? IMHO this topic is important. If
> > I'm wrong I would like to know it :)
>
> In many respects, this is a thread that should probably occur within
> the W3C and WHATWG lists, as how browsers handle credential collection
> is much more of an issue for them than the IETF..   Note that I think
> they are in final call on their APIs as well.
>
> It is true that the current version of the draft no longer denies the
> ability of a client to handle 401 responses, so that is perhaps all
> that we need.     However it might be that we should consider if we
> recommend support for BASIC and DIGEST.
>
> cheers
>
>
>
>
>
>
>
> >
> > 2011/6/20 Iñaki Baz Castillo <[e-mail]>:
> >> Hi, I would like to start a new thread for this topic as it seems that
> >> the draft does not cover it at all (just suggests that an HTTP
> >> response code other than 101 should be threated as RFC 2616 states:
> >>
> >>
> >>  "1.  If the status code received from the server is not 101, the
> >>        client handles the response per HTTP procedures." (p. 30)
> >>
> >>
> >> The question is: should the browser prompt the human user for
> >> user/pass as when a 401 is received in the WS handshake attemp?
> >>
> >> Imagine this case:
> >>
> >> - www.domain.org => 1.1.1.1:80
> >>
> >> - ws.domain.org => 1.1.1.2:443
> >>
> >> - I open http://www.domain.org in my browser, fill some login form and
> >> retrieve websocket connection data, including an user and pass (for
> >> Digest).
> >>
> >> - My JavaScript is then provisioned (via JavaScript WebSocket API
> >> ????) with ws connection data: server ip, port, Digest user/passwd.
> >>
> >> - My web browser starts the ws connection with ws.domain.org:443. It
> >> receives 401 with Digest (so I need a nonce from the server before
> >> using my user/passwd).
> >>
> >> - JavaScript code automatically accepts the Digest chanllenge,
> >> generates a Digest response with the provided user/passwd and the
> >> retrieved Digest nonce, and re-send the HTTP GET request (all of this
> >> without prompting the user) with the Authorization header.
> >>
> >> - If the JavaScript code would not be proviosioned with user/pass,
> >> then upon receipt of the 401 it should prompt the user (like a
> >> JavaScript alert?).
> >>
> >>
> >>
> >> So, if all this stuff is not clearly specified (and I think passing
> >> user/pass to the JavaScript WebSocket connection API does not exist)
> >> then using HTTP Digest (or Basic) will be not useful or feasible, and
> >> I expect than using cookies and all that "pure just-web stuff" will be
> >> the only way. Please, take into account that a websocket server could
> >> run in a separate server, so using cookies mechanism is not so
> >> feasible (it could or not depending the case). Neither I think that
> >> cookies (a workaround to simulate
> >> sessions in HTTP protocol) are the best way to go.
> >>
> >> IMHO the draft should do much more effort in authentication process.
> >> Please don't let the door open to ugly and/or propietary
> >> authentication solutions.
> >>
> >>
> >> My proposal is that the JavaScript WebSocket API should include a
> >> method to pass authentication 'user' and 'password' (and optionally
> >> 'realm' so it would ignore the realm para in the 401 response when
> >> using Digest rather than Basic auth).
> >>
> >> In this way, I could open a webpage, perform usual login (maybe via a
> >> HTML form as commonly extended) and then retrieve WS connection data
> >> (WS URI), including user/pass/[realm].
> >> So my JavaScript client would open a WS connection with the given
> >> destination and in case of receiving a 401 it would re-send the HTTP
> >> GET request with the appropriate Authorization header without
> >> prompting the user.
> >>
> >> This wouldn't be the only authentication mechanism, of course, but
> >> IMHO it should be documented (and covered by the JS WebSocket API).
> >>
> >> Regards.
> >>
> >> --
> >> Iñaki Baz Castillo
> >> <[e-mail]>
> >>
> >
> >
> >
> > --
> > Iñaki Baz Castillo
> > <[e-mail]>
> > _______________________________________________
> > hybi mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/hybi
> >
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>