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
