Investigate 401 handling for WebSocket

[annevk]

This is a follow-up to whatwg/fetch#565 and whatwg/fetch#761 (comment) in particular.

It'd be good to write more tests that cover the various scenarios:

1. Not authenticated, server replies with 401
2. Authenticated via fetch() with Authorization before opening the web socket connection.
3. 2, but server replies with a 401 anyway.
4. More?

Not sure all of those are easy to do in web-platform-tests given that authentication entries likely don't cross ports...

And review the algorithms in the standard again to ensure no prompting can take place ever (and maybe check again if implementations have the necessary bugs if they don't implement that).

[annevk]

websockets/basic-auth.any.js is an initial test by @ricea.

[ricea]

The difficulty with preflighting auth via XHR or fetch is that the pywebsocket API doesn't support basic auth for plain HTTP except by restarting it with different command-line arguments. I had an idea yesterday that we can test this more easily by using the regular (non-WebSocket) wptserve, but returning a 404 after auth succeeds. We won't be able to tell whether it succeeded using the WebSocket API, but we can ask the server whether auth succeeded after the WebSocket onclose handler is called.

Another trick I've used in the past is to return a canned WebSocket response containing only a close frame from an HTTP-only server. That's probably harder to understand than the 404 trick, however.

I don't have time to dedicate to this at the moment, but I will try to fit it in.

A case I'm particularly interested in trying is a digest authentication like this:

1. Cache credentials with XHR. HTTP GET / 401 response requesting digest auth / HTTP GET with Auth / 200 response sequence.
2. WebSocket GET without auth (some browsers may send auth immediately in some cases? the test should be flexible about this)
3. Server responds with 401 requesting digest auth
4. WebSocket GET with digest auth
5. Server responds with 401, indicating stale nonce, provides new nonce
6. WebSocket GET with digest auth, using new nonce
7. Success!

The idea is to get close to the multi-stage auth used by NTLM or Negotiate, without hitting the weird platform-specific behaviour that NTLM and Negotiate imply.

[annevk]

Thanks, I don't think there's any particular rush, but that sounds like a good strategy (I was also wondering how this would work with web-platform-tests and did not think of that trick).

We should also test @dveditz's scenario with differing realms.

[sleevi]

On Mon, Jun 18, 2018 at 2:08 AM Adam Rice ***@***.***> wrote: The idea is to get close to the multi-stage auth used by NTLM or Negotiate, without hitting the weird platform-specific behaviour that NTLM and Negotiate imply.

@ricea I’m not sure I fully understand your point, but the above scenario won’t get any closer than just doing basic auth, at least in Chrome. You either do the weird (platform-specific) bits or you don’t do it at all, but there’s no intermediate step you can get close to approximating.

[ricea]

@sleevi The part I'm interesting in exercising is handling more than one 401 response in the process of establishing a single WebSocket connection. I should have just said that explicitly, sorry.

Obviously it would be better to test real multi-stage auth, but I know of no realistically achievable way to do that in the web platform tests.