Re: [whatwg/fetch] Investigate 401 handling for WebSocket (#766)

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/766#issuecomment-397951045