- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
You must log in or register to comment.
Daisuke fixed a 22-year old bug and we now prevent passwords in URLs from being saved in history!
Interesting.
RIP that one guy who relied on this bug. He’s gonna have to create a bookmark now, which will ruin his whole workflow.
That’s good, but out of scope for a browser, really. Also there shouldn’t be passwords in URLs!
It is not out ot scope. Basic auth exists: https://username:[email protected]
I forgot about that. It shouldn’t, these days.
It is one of the easier ways to globally configure git auth for private Go packages.
I have this exact use case on a work machine, because the proxy flat refuses to prompt for the login, just goes straight to deny.
I own neither the proxy, nor the steaming heap of code that lives behind it, and I’m grateful for that every single day…
That just seems like crappy website design
It has nothing to do with website design. It’s part of the HTTP protocol. A poor part in today’s understanding and use cases, but in the 90s it would have made sense.
We’re both talking about route parameters right?
I think they’re talking about basic Auth, with which you can pass credentials in a URL like this:
I thought basic Auth was where you base64 encoded the username and password and sent it as the Authorization header
That is also a form of basic auth, you still pass the credentials like “username:password”, optionally base64 encoded but I don’t believe that’s required.
Edit: actually, after looking into it a bit more, it seems like passing credentials in the url will actually cause the browser to send it as an authorization header instead. So in essence it’s doing the same thing.
Oh wow, I’m pretty sure I reported this for Navigator.
This is some good stuff!
