💾 Archived View for rawtext.club › ~sloum › geminilist › 001497.gmi captured on 2020-09-24 at 01:50:44. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Petite Abeille petite.abeille at gmail.com
Wed Jun 10 13:18:47 BST 2020
- - - - - - - - - - - - - - - - - - -
On Jun 10, 2020, at 13:15, Felix Queißner <felix at masterq32.de> wrote:
I don't think that user/password is the right way to handle
authentication in Gemini.
Why not? Gemini mandates a secure communication channel (TLS) already. The userinfo is identical to the Basic Authentication scheme, but encoded the URL directly. Rather convenient altogether.
The URL RFC also specifies:
Use of the format "user:password" in the userinfo field is
deprecated.
This is more related to authentication over an open channel.
So only user@… is still a valid URL.
If your server handles user@ in a different way than without authority,
i think that's totally in-spec, but authentication is probably not.
I guess user@ could be any magic token/ticket, for the client to maintain a state on the server.
Perhaps a subset of 40 TEMPORARY FAILURE, e.g. 49 Unauthorized, would be an appropriate response if Authenticate: Basic is required by a resource.
One possible usage for authority could be home-dirs instead of an
official site:
I was more looking into a way for the client to maintain some states (e.g. preferences) on the server:
C: gemini://token@mozz.us/?ua=lightweight -- user-agent store its preferences on the serverS: 30 gemini://token@mozz.us/index.gmi-- redirect to an appropriate resourceC: gemini://token@mozz.us/index.gmi -- lightweight version of the resourceS: 20 text/gemini -- customized as per the user-agent stated preferences
A bit of content negotiation in other words.
For all practical purpose, it serves the same purpose as the various 6x (CLIENT CERTIFICATE REQUIRED) statuses. Minus the burden of the actual TLS gymnastic.