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

> Possibly I would do that by asking the user (using a much nicer form than the browser one!) to enter a username and password;

We call that phishing :)

> possibly I would use cookies;

That's not how HTTP auth works :)

> I don't understand why anything else would be desirable.

What you described cannot be implemented without crippling the platform and harassing users.

The TL;DR: is what you described can only be polyfilled for simple cases (which no one uses), not for the hard cases (for which a non-trivial, rather large position of our users use, and for which I guarantee you use every day without ever realizing)

Hopefully without sleevi-splaining too much, that simply doesn't work. There are authentication mechanisms that cannot be polyfilled by Javascript because they rely on interacting with the user and host OS (e.g. NTLM, Negotiate, Kerberos) in a way that's designed to be extensible (so we can't just spec all the ways because there are an infinite number of them) and, more importantly, to keep credentials opaque (and I mean opaque from the browser itself).

Imagine if Site X wants to use a Service Worker, and it wants to load resources from Site Y and Z (Z could be an intranet site, a vendor site, whatever). The SW only cares about loads/caching from Site X, but the Site Y/Z loads come in by virtue of us shunting all requests through the SW. In today's browsers, "magic" or not (really, it's a defined security boundary, and one we shouldn't just chuck out because it makes things hard), if a user has visited Z, we don't prompt them for credentials if we have them, and, on many platforms, we can avoid prompting for credentials all together by interacting with the OS in ways we absolutely must never expose to websites (in the most literal sense of never)

So you can't "polyfill" auth in these scenarios, and were you to, it would be detrimental to user security.

Now, if you're Site X talking about resource from fetch(X), then it still remains a case-by-case decision. A SW shouldn't have to (securely) maintain a credential store for X, and it should be able to share that credential with other loads (SW or not) and other subsystems. The solution you described simply doesn't allow for that.

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