Client cert double requests

[jbanana]

I've been using Deedum to play the spellbinding game at gemini://tilde.cafe/~spellbinding/game/cgi and I got an email from the person who runs it saying:

each time you send a word o Spellbinding, it sends it once without a certificate, then, presumably after asking you, it sends it again with your certificate. It is not causing me problems. If you have a line of communication with the developer, you may want to let them know.

I noticed that every time I submit a word, I have to choose the certificate, but I only have one.

I couldn't find a way to say "this cert applies to all requests to this host". Is that possible?

[snoe]

@jbanana
There is, if you goto gemini://tilde.cafe/~spellbinding/game/ or gemini://tilde.cafe/~spellbinding/ You can choose Add to Identity in the menu. In this way identities can be attached further up the path tree.

Why you need to do this for spellbinding is kinda interesting, and could be a bug in deedum (I'm inclined to think so), spellbinding or an ambiguous spec.

Start at gemini://tilde.cafe/~spellbinding/game/
Click "play a round" and goto gemini://tilde.cafe/~spellbinding/game/cgi?
Deedum asks for cert and attaches it to gemini://tilde.cafe/~spellbinding/game/cgi?
Click to submit a guess and get redirected to gemini://tilde.cafe/~spellbinding/game/cgi
Since cgi != cgi?Deedum asks for cert and attaches it to gemini://tilde.cafe/~spellbinding/game/cgi
Each subsequent guess applies cgi?guess and therefore asks for a cert again.

So, basically I didn't consider the query when I built it, and a such it is treated as part of the path. I could however see some people liking this behaviour as an entire site could be handled through queries like bad.site/?/user1/path. Nonetheless I'm inclined to have deedum ignore queries when pinning certs. PR welcome, otherwise I'll probably sit on this for a bit until others speak up as there is a workaround. https:/snoe/deedum/blob/master/lib/models/identity.dart#L79

1.2 Gemini URI scheme
The path, query and fragment components are allowed and have no special meanings beyond those defined by the generic syntax.

4.3 Client Certificates
Gemini requests will typically be made without a client certificate. If a requested resource requires a client certificate and one is not included in a request, the server can respond with a status code of 60, 61 or 62 (see Appendix 1 below for a description of all status codes related to client certificates). A client certificate which is generated or loaded in response to such a status code has its scope bound to the same hostname as the request URL and to all paths below the path of the request URL path. E.g. if a request for gemini://example.com/foo returns status 60 and the user chooses to generate a new client certificate in response to this, that same certificate should be used for subsequent requests to gemini://example.com/foo, gemini://example.com/foo/bar/, gemini://example.com/foo/bar/baz, etc., until such time as the user decides to delete the certificate or to temporarily deactivate it. Interactive clients for human users are strongly recommended to make such actions easy and to generally give users full control over the use of client certificates.