Re: "Hi all. I'm wondering: why does the Gemini specification…"
In: s/Gemini
For those curious as to what this is about, it's about including a username/password in the URL, like:
gemini://john:god@example.net/foo/bar
I'm partially responsible for this. Solderpunk was looking to add a reponse that asks for a username/password (like the above) when I suggested the use of client certificates as an alternative. My thinking at the time was the the server side could generate a certificate for the client to use to be granted authorization for parts of the site. Solderpunk took it in a completely different way, and then mandated that the user creditials in the URL was NOT the way to go.
👽 spc476
May 12 · 10 days ago
😎 flipperzero · May 12 at 20:38:
@spc476 omfg wow hi! thanks for joining us here part of the discussion on Bubble BBS and I hope you find your time nice. :D Ok sorry aside from fanboying RE OG mailing list matters ehehe
I think this was a very good, important contribution! Your thinking was correct - look at misfin. Try out gemini://woodpeckersnest.space:1958 as an example of such implementation. This is also possible client-side as evidenced by skyjake's lagrange. I don't see anything wrong with, and very much prefer, this approach of user interaction and data integration between client to server far more than sharing plaintext details YUCK!
@skyjake excuse my tardiness being late back to the party like this, but thank you very much for your cited reference as it's what I thought was the matter (which is also why I cringed as much in description as I was making detail haha)
So far, this method seems to work just fine, if not just doing so by either web frontend or remote shell interface (like what I do with my spot) and screening things that way.
🚀 mk270 · May 21 at 16:02:
The use of userinfo is also a vector for extending the protocol via a side-channel. I could be mistaken, but this was cited on that accursed mailing list as one of the reasons for banning it.
🚀 lars_the_bear [OP] · May 21 at 16:47:
@mk270 : "userinfo is also a vector for extending the protocol via a side-channel"
I suppose it could be, if you used it for something _other than_ authentication. I guess that's why URL fragments are banned, also.
I agree that it makes sense to ban userinfo if it _isn't_ used for authentication, but that doesn't explain why it's banned for authentication. I guess some of the forgoing disucssion explains that, but I still think it was the wrong decision, on balance.
Original Post
🌒 s/Gemini
🚀 lars_the_bear:
Hi all. I'm wondering: why does the Gemini specification object so strongly to using "userinfo" credentials in the URL? I can see the advantages of client certificates for technically-minded users, and for server-side developers. But user/password is a pretty common paradigm in the ordinary web. Does anybody know why the "userinfo" approach was so roundly rejected?
💬 16 comments · May 11 · 11 days ago