Re: [ServiceWorker] HTTP authentication and proxy authentication hook (#119)

> Client auth: Could we have an API within the document environment that triggers client auth UI and returns an opaque object you can use with a request (and message to a worker)? Is there some way to figure out if the server challenges you for client auth?

To do that would force a design constraint on client auth implementations that wouldn't be compatible with Firefox's current implementation, though compatible with Chrome's only through a (undesired) backwards compatibility quirk from when Chrome shared the same networking stack as IE (WinInet) before introducing its own network stack.

If you forced fetch() to invoke some user-level callback/promise during the authentication flow (to give an opaque object and let the S*W determine whether or not to prompt or not), then that design would be incompatible with Chrome's implementation, but compatible with FF's, but somewhat undesirable due to introducing a whole new host of edge cases that app developers would potentially have to work around (this is an issue FF already has w/r/t edge cases and non-determinism).

So both end up in a somewhat weird/undesirable state.

> Workers: Does Chrome never trigger UI in workers? Not even for HTTP proxy auth? It would certainly be my preference that workers cannot trigger UI and fetch() cannot either.

Due to the complexities of Chrome's current SW implementation, I don't have an answer based on first principles/code inspection. It's one of those "¯\_ツ_/¯" situations where whatever we due experimentally isn't necessarily because of any intentionality of design or expectation of behaviour.

An initial solution would be "Don't prompt at all", which is far more consistent and reasonable. A longer term solution worth exploring is whether we can use the [FetchEvent.client](https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#fetch-event-interface) into the [RequestInit](https://fetch.spec.whatwg.org/#requestinit), such that any user interaction happens in the context of the [Client](https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#client-interface).

That is, in order to make a sensible story for prompting, I think our inclination is there needs to be some way for the S*W to tag the fetch() invocation with the client - either through [GlobalFetch](https://fetch.spec.whatwg.org/#fetch-method) having a way to specify the client, or by having [Client](https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#client-interface) implement `GlobalFetch` as a specialization of the general Fetch. I'm more inclined to make it the 'explicitly supplied via RequestInit' than 'implicitly supplied based on object you're calling', but what do I know?

---
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/119#issuecomment-118338101