[guntars]

Needing a bunch of JavaScript to make it work, which will get bungled by the devs and break it for people using password managers, making the thing even worse. Login is such a common pattern that it should be just handled by the browser.

[cpeterso]

Good point. It's unfortunate that HTTP Auth never become popular. I don't know if that was because the browser support or UX was bad or if web developers wanted more control over their sites' login flow or user information required.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentica...

[efreak]

The problem is that you have a few options:

1. send in plain text with http basic auth. Over https this isn't a problem, but https was expensive). This is sent on every request. 2. Use digest. This is also sent on every request, and also requires actual processing, at which point you might as well go for 4 so it looks nice. 3. Use certificates. Nobody does this on the pubic web. The only website I've ever used certificates was whatever certificate site predated let's encrypt, can't remember the name at the moment, and as someone who doesn't use client certificates it was a huge pain (blame that on the browsers though) 4. Use a form on the website with a session token, and you get control over the UI including error messages and styling. Much more user-friendly. You can trivially prevent the user from (easily) sending requests with pain text passwords by only showing sensitive pages like login over https. The user can't bookmark or share a URL with a password embedded in it. You can request more information than just username and password (Bank: do you want to see your checking account or savings account? Forum: go back to previous page or to homepage? SSO-ish (DayForce): what's the name of the org you're signing into?)