I’m using the parameter described at:
…and I have a coupe of issues.
I’d like to have a wiki which is world-readable, and writable by authenticated users. My guess, under the shell script:
#!/bin/sh
tiddywiki whatever --listen \
[...irrelevant stuff...] \
credentials=creds.csv \
"readers=(anon)" \
writers=michael
The behavior of my wiki has been unpredictable.
Currently, I’m getting a wiki which is world-readable only. The “writers” part doesn’t seem to be in effect.
A hitch: it’s hard to be sure that my setup is currently in effect, and, which such setup applies on the browser end.
I’ve tried varying sequences of:
- changes within the “creds.csv” file;
- restart the web server (nginx);
- restart the shell script where tiddlywiki is running;
- stop the shell script; reload at the browser (to force “file not found”); restart the script and restart the browser side;
- switch around between “readers=(anon)”, “readers=(authenticated)”, and (varying entries under) the “writers=” entry;
- force restart of my browser (shift-reload as opposed to just a reload of the page)
Whatever I’ve done on the server side, it’s rare that my page is fully reloaded at the browser. Sometimes I do get the user/password prompt, but not very often, and I don’t see any way to force a complete reload. Specifically, once I have a session with “writers=” enabled, changes on that entry at the script end don’t seem to matter from the browser right away.
As I write this, my current user session is the “anon” kind – the page reloads with no errors, but no “write” options appear (create a tiddler, synchronization). Earlier, the full writable status was appearing, but I haven’t been able to narrow down how to force a switch among the various settings.
It’d be handy to have more than one entry under the “credentials=” file, then, as a user, restart a session between those user states. Or, short of that, to reload different versions of that .csv file; either way though, what I find is that it seems my browser keeps some set of data that it reloaded in some past session. That makes it difficult to verify that the current status of the shell script is up to date.
One thought I had: taking out the “user-browser-cache=” setting, maybe that would stop the pattern of having the browser send whatever it might have cached. It didn’t make any difference other than (as expected) slower reloads of a page.
Hints? Thanks.