bmarinov@lemmy.world
on 03 Apr 2024 07:05
collapse
It is one of the easier ways to globally configure git auth for private Go packages.
flashgnash@lemm.ee
on 02 Apr 2024 19:50
nextcollapse
That just seems like crappy website design
strcrssd@kbin.social
on 02 Apr 2024 20:18
collapse
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.
I thought basic Auth was where you base64 encoded the username and password and sent it as the Authorization header
Ghoelian@lemmy.dbzer0.com
on 03 Apr 2024 11:43
collapse
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.
xlash123@sh.itjust.works
on 02 Apr 2024 20:42
nextcollapse
RIP that one guy who relied on this bug. He’s gonna have to create a bookmark now, which will ruin his whole workflow.
AnUnusualRelic@lemmy.world
on 02 Apr 2024 20:51
collapse
Oh wow, I’m pretty sure I reported this for Navigator.
threaded - newest
Interesting.
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: username:password@example.com
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…
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.
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:
username:password@website.com
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.
RIP that one guy who relied on this bug. He’s gonna have to create a bookmark now, which will ruin his whole workflow.
Oh wow, I’m pretty sure I reported this for Navigator.
This is some good stuff!