implementing client certificate support

[Michael Lazar]

On Sun, Jun 7, 2020 at 7:14 PM <mbays at sdf.org> wrote:
>
> This doesn't work entirely smoothly with astrobotony -- you might start
> using our certificate at gemini://astrobotany.mozz.us/plant/, so it then
> also takes effect for gemini://astrobotany.mozz.us/plant/water and so
> on, but if you try e.g. gemini://astrobotany.mozz.us/settings you have
> to select the identity again. You can manually "identify
> gemini://astrobotany.mozz.us", but that isn't so smooth. Probably marks
> should optionally have an identity associated -- that would help quite
> a bit, but needs some forethought from the user.

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.

- Michael (mozz)