💾 Archived View for rawtext.club › ~sloum › geminilist › 001427.gmi captured on 2020-09-24 at 01:53:22. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
solderpunk solderpunk at SDF.ORG
Mon Jun 8 18:24:51 BST 2020
- - - - - - - - - - - - - - - - - - -
On Sun, Jun 07, 2020 at 10:00:02PM -0400, Michael Lazar wrote:
For what it's worth, I have been thinking about reorganizing the URL
structure for astrobotany so that all of the authenticated endpoints
live behind a single path. I am also planning on adding more
unauthenticated content to the server, so I want to establish a
clear separation between the sections that require a client certificate
and the sections that do not.
- gemini://astrobotany.mozz.us/
- gemini://astrobotany.mozz.us/about
- gemini://astrobotany.mozz.us/app (requires client certificate)
- gemini://astrobotany.mozz.us/app/plant
- gemini://astrobotany.mozz.us/app/directory
- ...
There are several other advantages to having a well designed path
hierarchy. It's something that I often don't spend enough time
thinking about up front and then I regret not doing it right later.
This seems wise to me. It's already pretty clear that associatingclient certificates with domains, as currently specced (for transientcerts, at least) and as implemented in AV-98, is not the best idea. Itwill inevitably cause confusion/frustration/difficulty in environmentswhere multiple users share a domain (like pubnixes). Associating themwith paths seems the obvious solution.
As the current leading implementer of client cert consumning apps, I'mcurious how you feel about the idea of using the <META> for 6x statusesto convey an intended "path scope" for certs?
Cheers,Solderpunk