Read only mode: how to hide content from tiddler body?

[Odin]

Hi all!

I am using tiddlywiki to host a wiki for my dnd players. I am hosting this wiki using node.js and keep all my notes in it. My players can only view a version of this wiki that is static html file export of the wiki. This way I prevent them from doing edits, and seeing notes that should still be a secret for them.

To keep secrets out of the static file export i used this filter, to write secret info within the tiddler body, so it is part of the text flow for me:

<!-- Text within this list will be hidden in the eport  -->
<$list filter="[<tv-config-toolbar-icons>prefix[yes]]" variable=0>

this is a secret line within the text

</$list>

I think I got this snippet somewhere on this forum. I am also using a filter on the static file export to exclude many tiddlers from being exported, to keep those notes hidden.

My players expressed they they struggle finding stuff, now the wiki is expanding and I am also running into the limits of the static html exports. So ideally I want to keep a interactive version of the wiki that is readonly for my players. And then a edit version of the wiki for myself.

Using https://tiddlywiki.com/#ListenCommand I host the wiki as readonly, and have login credentials for myself to edit it.

Is there a way to then also check the visiters rights to dynamically show content? And ideally part of the tiddler body? So that non logged in users can read only the public parts, and I can keep my hidden notes part of the same wiki?

[hr-sbu]

A very quick and spontaneous idea, as I’m not an expert on that use case, maybe the real experts could chip in on that plan:

• I imagine there was a way to prevent editing (e.g. hide all New/Edit buttons and those alike), that would give us the readonly part
• now, you could add a magic tiddler, where you enter a password (for example), which gets stored in a temp tiddler
• then, you implement your own toolbar edit/new/whatever buttons, by simply putting filters around the standard buttons, with the filter only showing the button if the password matches

I have once done some CSS in a similar way, which hides pretty much of the controls under certain conditions (in my case that was a special class in the surrounding Iframe, but I guess you could make CSS conditional in TW with some clever filtering).

[Odin]

Authentication and readonly is already working out of the box with nodejs, see: https://tiddlywiki.com/#ListenCommand

I am looking for conditionally showing tiddlers and content based on a user being authenticated or not.

[Scott_Sauyet]

@Odin

My players expressed they they struggle finding stuff, now the wiki is expanding and I am also running into the limits of the static html exports. So ideally I want to keep a interactive version of the wiki that is readonly for my players. And then a edit version of the wiki for myself.

I don’t know if my techniques would suit you. It depends on whether you only want to keep the extra information from casually wandering eyes or to ensure it’s not visible to a TW-sophisticated hacker.

Mine only handles the former. But it’s worked well for me across many projects. You can download the following and drag it to a wiki:

ReadOnlySettings.json (4.1 KB)

You will need to save and reload, since there’s a startup action included. This offers a read-only mode and turns it on by default if I’m not running in Node. I can toggle that with the keystroke CTRL-SHIFT-/ (or because that may not work on certain keyboards, with CTRL-SHIFT-1.) So when I build and deploy my wiki to GH Pages or similar, it’s read-only mode, but I can easily toggle into edit mode.

Yes, this is security-by-obscurity. I would not do this if I was worried about someone peeking behind the curtain. But that’s not my concern; it may be yours. Instead, I simply don’t want to confuse users with things that seem to offer them the ability to change but which they can’t update on my read-only servers.

That code really needs to be updated. We discussed this in #12964. It shouldn’t be difficult, but I’ve never gotten back to it. The code works fine for me, though.

@Odin

To keep secrets out of the static file export i used this filter, to write secret info within the tiddler body, so it is part of the text flow for me:

<!-- Text within this list will be hidden in the eport  -->
<$list filter="[<tv-config-toolbar-icons>prefix[yes]]" variable=0>

this is a secret line within the text

</$list>

I find it a little simpler to write a custom widget to do the same thing:

title: $:/_/my/widget/edit-only
tags: $:/tags/Global

\widget $edit.only()
<% if [{$:/status/IsReaderMode}!match[yes]] %>
<$slot $name="ts-raw" />
<% endif %>
\end

Then it can be used like this:

This is <$edit.only>NOT </$edit.only>in read-only mode. 

<$edit.only>

Handles block mode (if you start with a newline),

[[Links|https://google.com]], and //so on// ''work'' as expected.
</$edit.only>

Read-only

Edit mode

[TW_Tones]

If security by obscurity is not sufficient you may need to have your notes in encrypted tiddlers. Once MWS multiwiki server is mature you will be able to publish wikis with suites of tiddlers not readable by some users. However I recommend you design your wiki so the notes are not part of the content but in a related tiddler. This gives you the necessary control over the content which you want to make conditional.

Over hear Tips and commentary - Notes on tiddlers stored in a data tiddler I wrote

@TW_Tones

The following is a TiddlyWiki script solution to place multi-line notes on any tiddler, with wikitext, but stored in a data tiddler. This means the tiddler on which the note is added is not touched.

It has been written not to demonstrate the perfect solution, but to demonstrate a range of tips and tricks. If you work through the notes you are likely to learn a lot, and if not you have a subject on which to raise a trick you have found.

Perhaps we could extend this to use a simple form of encryption to store the notes, and use a bookmarklet in your browser to install the key in a tiddler, but not save this tiddler with the wiki. So you just click a bookmarklet to read and edit the notes but visitors will not see them even if they open the note database.

[Odin]

Thank you for this comment. The tiddler: $:/status/IsReaderMode is exactly what I need for my implementation!

[Springer]

There are lots of good suggestions here.

For my teaching wikis, I do use some elements of “security by obscurity” … When the info is just not what students need to see, so I tuck into pockets that are “display:none;” for read-only viewers. (I’m not on node, but on tiddlyhost, but similar read-only tricks work for both cases.)

But I also have a “selective-save” trick, for anything that really needs not to be even in the wiki file where savvy users could pry and/or simply view source to comb through for sensitive data.

If there are specific tiddlers where the secrets live, then you can exclude them from your “publish” filter:

Make a tiddler (I call mine $:/publishFilter) with the tag $:/tags/Global and a line of text something like:

\procedure publishFilter() -[tag[secret-stuff]] -[class[DM-notes]]

Then, you also would need a separate procedure to make sure that you export all that yummy secret stuff to an offline location. (Do it as often as you save to server, maybe with some automated workflow.)

That’s what I do with my grade-bearing and student-confidential tiddlers: they don’t get saved to tiddlyhost. So students can see everything they need to see, and when I load the file in my own browser (if I’m doing grade-related stuff), I drag in the JSON containing roster info and grade details.

(It’s a bit more complex — the student data is actually nearly all in there, just not identifiably so. That allows my university LMS to load the wiki using url parameters filled in with student-identifying strings… which can be processed on load to filter for that student’s anonymous-looking tiddlers… so that each logged-in student sees “their own” work and their own feedback, but without that info being identifiably in the wiki on the server.)

Feel free to follow up if this kind of approach interests you.

[TW_Tones]

@Springer

That allows my university LMS to load the wiki using url parameters filled in with student-identifying strings…

This is a great example of integrating tiddlywiki into other solutions. I have long wanted to do something similar inside WordPress. Where the user credentials give them access to their own TiddlyWiki but the teacher has access to all the wikis. The only complications are that WordPress stores most content in the database.

But @Springer your example is a key validation of the value of integration and user based wikis. I love it

[Springer]

@TW_Tones

your example is a key validation of the value of integration and user based wikis.

I should say that such integration is not necessarily easy for mere mortals .

I had to persuade my IT folks to install a moodle “plugin” at the server end that allows various student-specific data-strings to be called up, within my content panes, for that authenticated student (including as url parameters). And the IT folks really were very wary of installing anything from the open-source world of coding that could (in theory, from their point of view) cause data-leaks or memory-leaks or GUI glitches or performance drag, etc.

It’s working well for now, but the world of Learning Management System tech is a complex ecosystem!