[tw5] Sending tm-save-wiki while running as WebServer and avoiding the download dialog

OK, let me preface this by saying that I am trying to selectively get around the read-only mode on my wiki.

I usually run my main instance with anon access for readers and authenticated for writers. It’s great and does the job.
But, I want to be able to allow changes by anons for some tiddlers. specifically, I want users to be able to click a button which does an ActionSendMessage of tm-add-tag or tm-remove-tag. But this button only shows up in some tiddlers based on their tags.
Now, I did add another sendmessage of tm-save-wiki to that button which does save the changed tiddler. Unfortunately, i also triggers the download dialog for the html file which is undesirable.

Is there any way I can force a save without getting that dialog?
Is there a better way I can do what I am trying to do?

Write access is all-or-nothing, so if you grant write access to anonymous users they will be able to change anything, not just the tags of interest.

It might be possible to modify $:/config/SyncFilter so that only the tagged tiddlers are synced, but at the moment that’s a per-wiki setting that would be shared between all users. That could be worked around by using the includeWiki mechanism to make a clone of the wiki with different settings, and then have anon and signed in users access the system through different URLs.

By the way, under Node.js there’s no need to send the tm-save-wiki message; changes are synced back to the server automatically. Sending the message just engages the usual saver mechanism as in the single file edition.

Best wishes


I think how I’d set things up:

Those few tiddlers you want anonymous users to edit, put those in another TiddlyWiki, say TiddlyWiki B. TiddlyWiki A being the one you referenced in your OP.

Setup TiddlyWiki A to include TiddlyWiki B.

For tiddlers from TiddlyWiki B, setup an alternative “edit mechanism”, i.e. a button that pops open that tiddler in a new window that opens TiddlyWiki B, with the tiddler from B open for editing. Maybe a setup so that a user can do nothing but edit the specific tiddler (i.e. no access to all the other goodies in TiddlyWiki B. (Using the HTML dialog element in a TiddlyWiki B tiddler, you could cover the entire browser page with an editor for the one tiddler. No access to anything else TiddlyWiki B. The user presses save button. )

As an alternative to including TiddlyWiki B tiddlers in TiddlyWiki A, it might be better to have iframe’s in TiddlyWiki A that show tiddlers from TiddlyWiki B and allow editing right there. Reason: TiddlyWiki A won’t show the latest and greatest from TiddlyWiki B until TiddlyWiki A is restarted. But if TiddlyWiki A shows TiddlyWiki B in iframe windows, no problemo.

Based what you said, I took a sojourn into private mode and confirmed that I was probably logged in without realizing it when I tested this setup. Roger on everything you said, then. I probably should just separate it into two wikis, which I had been thinking about anyway.

Alternatively, you could setup a “guest” login account that anybody could use to edit only certain tiddlers.

For that to work requires some trickery that allows only certain users to do certain things for certain tiddlers.

It is a setup for fine-grained user-id/role fine-grained control which I seem to have working, but have no time to explain. Just know it can be done, just with tiddlers.

Arg. I forgot to mention there is one kind in the setup: tiddler import mechanism.

An enterprising and knowledgeable-enough TiddlyWiki user can break my secure setup by dragging and dropping a tiddler that totally up-ends my fine-grained security. That’s the one thing I need to resolve.

Poop. Typo: there is one KINK in the setup.

Yeah, security isn’t really my aim here. I back it all up regularly so it’s really just a) trying to save me from someone that felt like being a d*ck and b) family getting confused when roaming around. My family, on both my side and my wife’s, like for me to keep a wishlist. So I have it on my wiki. For them to be able to check things off the wishlist, they need write access. But they don’t want to have to mess around with logins. moving those tiddlers into their own instance might wind up being the best option.

Totally agree. It is a fool’s errand to think one can secure TiddlyWiki, unless I’ve missed something somewhere that says otherwise.

I’m just about minimizing the pains in the caboose caused by human error, by computer-related total foulups, and certain kind of folk who should crawl back in their holes.

BTW, thanks to our discussion here, I’ve just figured out how to thwart folk doing drag and drop for tiddler import. That dialog html element to the rescue. Très très cool.