💾 Archived View for rawtext.club › ~sloum › geminilist › 001753.gmi captured on 2020-09-24 at 01:40:07. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
solderpunk solderpunk at SDF.ORG
Wed Jun 17 11:02:21 BST 2020
- - - - - - - - - - - - - - - - - - -
On Wed, Jun 17, 2020 at 12:53:32AM -0700, Meff wrote:
You mentioned that you would like to see *no* cross-domain linking, in order
to remove the complexities of having to do some sort of CSRF-style
validation. The thing is, I think cross-domain linking is useful. It's
useful when replying to someone's Gemlog post, it's useful when creating
lists of links you would like to recommend to visitors of your capsule, and
for linking to sources of truth that may live elsewhere (especially if
linking against the web).
You have misunderstood! The stuff about no cross-domain linking wasstrictly in the context of a "safety client" for very safely using acertificate-secured app. In the context of a reading-oriented clientfor browsing gemlogs etc., *of course* cross-domain linking isabsolutely essential and a client which didn't allow it would beuseless.
How about a relaxed version of this, where all clients that wish to "follow"
cross-domain links *must* strip out any query params. For basic clients,
that would be as simple as a regex that strips the "?" used to start a query
string, and everything that comes after. For more sophisticated clients that
have access to URL processing libraries, this should be as simple as parsing
the URL, removing any query strings, and hydrating this URL again. Now
cross-domain requests cannot contain any sort of "payload" that the server
would mutate state with. Of course, there is the possibility that a page
view for an URL even without a query param would mutate state on the server,
but that is already an issue now.
This is a perfectly good idea for "everyday" clients to implement, inorder to make life a bit easier for people who really want to build anduse apps that don't hide behind a certificate requirement. It wouldmake it impossible to, e.g., link to a GUS search result page, though.That could be fixed if gemini://gus.guru/search?foo redirected togemini://gus.guru/search/marbles, but maybe it's not worth it.
In general, requiring all non-idempotent requests to use a query andrecommending clients to strip (or ask for confirmation of) queries foundin links and redirects, might be enough to solve the worst of theproblem. It would make applications quite a bit clunkier to use (Iguess they would need to use status code 10 to ask "Are you sure?" toevery non-idempotent request), but some people might find that less clunkythan using certs, I guess.
Cheers,Solderpunk