EnigmaCurry / d.rymcg.tech

A collection of self-hosted docker-compose projects with Traefik reverse proxy, integrated auth, and administrative Makefiles for easy maintainance
MIT License
49 stars 8 forks source link

Tiddlywiki #220

Open EnigmaCurry opened 4 months ago

EnigmaCurry commented 4 months ago

Refactor tiddlywiki to support multiple authentication backends.

Fixes #129

mcmikemn commented 4 months ago

I received this comment from @EnigmaCurry via email with link to this issue, but I don't see the comment on this PR: In order to make this like it was, where the public and private site shared the same domain name, it would necessitate a new plugin middleware that checks the header X-Forwarded-User AFTER the sentry auth middleware takes affect. For my use-case, I wouldn't care if public and private had different domain names. At the moment I only use Tiddlywiki privately and if I switched to wanting a public-facing URL I'd be find with a different domain for my private use.

EnigmaCurry commented 4 months ago

I deleted the comment because its incorrect. I don't know how it would be possible to use the same domain at all. It would have to be separate using the new auth stuff.

The benefit before of it being the same, was that way you could just copy the URL from the browser and share it. Now it will have to be different.

mcmikemn commented 4 months ago

Do you use Tiddlywiki as both private and public?

EnigmaCurry commented 4 months ago

That's the way its designed: an admin site that you must login to (only HTTP Basic supported) to be able to edit pages. If you don't send the auth, it reverts to a different server, one that only hosts a static public snapshot, one where editing pages has no effect.

TW itself has no concept of control of who can edit pages, and so public users can still edit pages, but they don't get saved on the server, and go away if you refresh the page.

mcmikemn commented 4 months ago

Well, separate private and public domains works for me, as I'll only use it via private.