You can log the user out by changing the “realm” parameter, which is a freeform string and can be quite long. As well, setting realm will cause devtools to use cached credentials similar to a new tab.

“No themed login form” oh no! Anyway. (I really think that the “theming” on login and sign-up forms breaches which bits are done by the browser and which bits are not. We’ve had to kludge back support)

I wish there was better browser support for this but I still use it for pet projects. Last year I wrote about why I’m still using HTTP Basic Auth.

https://joeldare.com/why-im-using-http-basic-auth-in-2022

Safari on iOS does not play nice with Basic Auth. No credential saving, re-promting you for credentials on each page you navigate to.

non-iOS browsers seem to handle HTTP basic auth gracefully.

There was a time that I can remember practically every site that needed a login using basic auth, before people switched to textboxes.

Maybe you don't listen on port 80 but I can imagine a standard web server using Let's Encrypt, for example, that could suffer from a user leaking credentials by inadvertently using HTTP rather than HTTPS.

I have to look into some protections to this. I recently did a project and used Basic Auth for expediency thinking that later I would replace with a "proper" auth form. My theory was that this was better because sending cookies is based on the protocol also not just the domain.

Know what my favorite part of the whole modern auth is? The most "reliable and secure" way to enter and transmit credentials is the browser. You know, that thing that has had absolutely tons of footguns with XSS problems, terrible cookie management/stealing, and generally leaving things up to websites to do auth.

They're even deprecating auth via non-browser means in newer OAuth/GNAP standards. It's like they're designing around what things are now, rather than thinking ahead as to what would be best. Like rather than website - managed auth, it be fully browser controlled (not HTML forms). Not cookies, but something prescribed by the browser (or whatever other application you might use, rather than needing to embed a browser yet again in everything).

> This is what HTTP auth headers are for, but the UX for using header authentication on modern browsers is utter garbage.

I had assumed the cause was something like this: Product management people want functionality which is fundamentally incompatible with security-- like complete control of the appearance and behavior of the login form (which can't be squared with impersonation attacks). Security people substantially control the https auth experience, and say NO. Product management people say fine, and just don't use the secure login functionality.

Everyone is happy: PMs get the security dumpster fire they asked for, Security people keep their perfect ice castle and can complain that all breaches are the fault of the PMs doing the wrong stuff. Except the users, of course, who get a needlessly insecure experience because there are many improvements to the http auth process that don't substantially compromise security.