Re: [hybi] Authentication headers

[Wellington Fernando de Macedo <[e-mail]>]

> Also, it isn't true. Again, all available Mozilla's http authentication
(like digest) work with websocket.

Well, I said something wrong... Actually digest with websockets just works
when connecting to the proxy.
Sorry.

2010/7/21 Wellington Fernando de Macedo <[e-mail]>

> > For example, the only authentication scheme that would work and be secure
> is Basic auth
> > over TLS to the same host as served the HTML page.
>
> Also, it isn't true. Again, all available Mozilla's http authentication
> (like digest) work with websocket.
>
> 2010/7/21 Ian Hickson <[e-mail]>
>
> On Mon, 7 Jun 2010, Wellington Fernando de Macedo wrote:
>> >
>> > I'm updating the Mozilla's implementation of the WS protocol to its
>> > latest version (v.76). I know that handling the 401 http response was
>> > already removed in the v75. But now I've noted that even the http
>> > Authorization header has been removed.
>> >
>> > Well, I think that the 401 http status was removed in order to prevent
>> > the browser to open unexpected auth dialogs to the user. Actually, I
>> > know there is the cookie information, but I think it isn't always
>> > enough. So, I would like to ask, why can't a "normal" request include
>> > the Authorization header from its page origin?
>>
>> There's some commented-out text to that effect, but frankly it's not clear
>> to me that it would be particularly useful in practice. For example, the
>> only authentication scheme that would work and be secure is Basic auth
>> over TLS to the same host as served the HTML page. In practice, only very
>> few sites use that combination of technologies; the cost of supporting it
>> seems higher than the benefit gained from it. It also seems unreliable; it
>> relies on the browser remembering the credentials used when loading the
>> Web page, for instance. There are also a number of situations where it
>> would seem that it should work but where it won't, for example if a page
>> on one path uses pushState() to go to another path and then opens a
>> WebSocket connection to the same host with the second path, the UA would
>> not know the realm of the second path and thus wouldn't know to include
>> the authentication information.
>>
>> Basically, it seemed hacky. I couldn't really find a compelling argument
>> to support this rather than having it at the application layer. (You can
>> still leverage the basic auth feature that way, just have the server send
>> back a unique token that identifies the user's session and then pass that
>> back on the WebSocket connection.) Cookies are supported because they are
>> _very_ widely used, so there's something to reuse. HTTP auth is used so
>> rarely that I'd seriously consider dropping it from HTTP at this point; I
>> really don't think it's worth adding to WebSockets.
>>
>> --
>> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
>> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
>> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>>
>
>