[whatwg] Issues with Web Sockets API

17.10.2009, ? 3:20, Ian Hickson ???????(?):

> I'm not really sure what else to say to be honest. Should I just  
> leave it
> at cookies and nothing else? Really I just want to support Basic  
> (and I
> guess Digest) authentication (primarily for over-TLS connections),  
> so that
> sites that use Basic auth, like, say, porn sites, or the W3C, can  
> also use
> it for their Web Socket connections. I could just limit it that way;  
> would
> that work?

Formally limiting support for Basic auth would be workable, I guess.  
Implementation of Digest authentication is already non-trivial enough  
for me to wish that we don't implement it at first.

Or perhaps authentication should be limited to cookies in v1 indeed.

>>>>> If /code/, interpreted as ASCII, is "401", then let /mode/ be
>>>>> _authenticate_. Otherwise, fail the Web Socket connection and
>>>>> abort these steps.
>>>>
>>>> 407 (proxy authenticate) also likely needs to be supported.
>>>
>>> Proxies wouldn't work with WebSockets in general.
>>
>> Could you please elaborate? I thought there was a setup that could  
>> work
>> with most deployed HTTPS proxies - one could run WebSockets server on
>> port 443.
>
> Oh, I see what you're saying. Proxy authentication of this nature is
> covered by step 2 of the handshake algorithm, as part of "connect to  
> that
> proxy and ask it to open a TCP/IP connection to the host given by / 
> host/
> and the port given by /port/". There's even an example showing auth
> headers being sent to the proxy. By the time we get down to parsing  
> the
> response, we're long past the point where we might be authenticating  
> to a
> proxy. Is that a problem?

Hmm, I actually don't know for sure. Step 2 only covers the case when  
the user agent is configured to use a proxy - but an organization may  
have a transparent proxy intercepting requests. But I do not know if  
such a proxy can practically request authentication by returning a 407  
response (blurring the meaning of "transparent" a bit, but anyway).

> I could add support for 407 here and just say
> that you jump back to step 2 and include the authentication this time,
> would that work?

If the answer to my above concern is yes, then it should work, as long  
as the text doesn't require double TLS handshake or something like that.

>>>> Some authentication schemes (e.g. NTLM) work on connection basis,  
>>>> so
>>>> I don't think that closing the connection right after receiving a
>>>> challenge can work with them.
>>>
>>> Yeah, that's quite possible.
>>
>> Is this something you plan to correct in the spec?
>
> Is there much to correct? I don't understand what would need to change
> here. Does NTLM not work with HTTP without pipelining?

You probably meant HTTP persistent connections here, not pipelining.  
Yes, since NTLM authentication works on connections and not individual  
requests, closing the connection after receiving a challenge will make  
it inoperable, as far as I know.

> Or do you mean that
> you would rather have authentication be a first-class primitive  
> operation
> in Web Socket, instead of relying on the HTTP features? We could do  
> that:
> instead of faking an HTTP communication, we could have a header in the
> handshake that means "after this, the client must send one more  
> handshake
> consisting of an authentication token", and if the UA fails to send  
> the
> right extra bit, then fail. I think if we did this, we'd want to punt
> until version 2, though.


Yes, I think that relying on HTTP specs to define authentication to  
Web Sockets takes the "fake HTTP handshake" concept too far.

- WBR, Alexey Proskuryakov

Received on Thursday, 22 October 2009 10:30:29 UTC