URL Protocol & Read Only Wikis

Tips & Tricks
1

If you are looking to setup a read only wiki, you can create a startup action tiddler with the tag $:/tags/StartupAction and having the tiddler field set accordingly

<%if [{$:/info/url/protocol}match[file:]] %>
  <$action-setfield $tiddler="$:/TLS/State/EditMode" $field="editMode" $value="true" />
<%elseif [{$:/info/url/protocol}match[https:]] %>
  <$action-setfield $tiddler="$:/TLS/State/EditMode" $field="editMode" $value="false" />
<%elseif [{$:/info/url/protocol}match[http:]] %>
  <$action-setfield $tiddler="$:/TLS/State/EditMode" $field="editMode" $value="false" />
<%elseif [{$:/info/url/protocol}match[content:]] %>
  <$action-setfield $tiddler="$:/TLS/State/EditMode" $field="editMode" $value="true" />
<%endif%>

Note the additional test for Android using Tiddloid, it has the protocol ‘content:’.

This tiddler will be actioned when opening the wiki and, in this case, set the appropriate field to true or false.

Then in your wiki tiddlers, you can simply test for edit mode with the statement

<%if [{$:/TLS/State/EditMode!!editMode}match[true]] %>
...
<%endif%>

I’m getting better!!

bobj

2 Likes
2

Here’s a much shorter bit of “startup” code that achieves the same result:

<$action-setfield $tiddler="$:/TLS/State/EditMode" $field="editMode"
   $value={{{ [{$:/info/url/protocol}prefix[http]then[false]else[true]] }}} />

Note the use of prefix[http] instead of match[...]. This covers both “remote access” protocols (http: and https:), and defaults to editMode=“true” for all other protocols.

-e

3

Just in case, I’d like to say This is a fake read only mode, user could still use HTTP api to update or delete tiddlers on your http server.

I see you try to prevent this by set readonly mode when match[http:], But it is easily hackable.

A real readonly mode can be achieved by setting a random password on server start, It will also hide all editing buttons, But also make it really not hackable read only.

4

@linonetwo, you are correct of course, it is fake read only mode. But our demographic, mainly members of the public, won’t realise it is fake as all edit buttons are hid by a style sheet, as I mentioned in an earlier posting.

The setting of read mode, in this case, allows me to hide specific edit buttons in the interface when our users, using a browser to access the server copy, access the content as well as hiding various $list outputs showing changes made over the past seven days, etc.

Editors will access a copy of the wiki on their computers.

The other nice thing about this is that if a determined and knowledgeable users bypasses read mode and edits tiddlers, the server copy remains un updated as the updated copy gets saved on their computers and not the server.

Bobj

5

Wouldn’t this generate a false “false” for tiddlyhost-authored sites? TiddlyTweaks’ read-only solution defines the read-only state this way:

\define read-only-filter()
    [[TiddlyWiki Safe Mode]is[tiddler]]
    [{$:/status/IsLoggedIn}match[yes]]
    [{$:/info/url/protocol}match[file:]]
    [{$:/info/url/hostname}match[localhost]]
\end

… where the $:/status/IsLoggedIn is served up by TiddlyHost as “yes” only when the wiki is opened from tiddlyhost control panel (and/or when tiddlyhost control panel is already open within browser session — I’m not sure on the exact details, but it works pretty well for me).

6

I always do all my editing locally, so I was not considering working online via tiddlyhost.

If I am reading it correctly, your filter returns a value when editing should be allowed.

Thus, @Bob_Jansen could use it like this:

\define read-only-filter()
    [[TiddlyWiki Safe Mode]is[tiddler]]
    [{$:/status/IsLoggedIn}match[yes]]
    [{$:/info/url/protocol}match[file:]]
    [{$:/info/url/hostname}match[localhost]]
\end
<$action-setfield $tiddler="$:/TLS/State/EditMode" $field="editMode"
   $value={{{ [subfilter<read-only-filter>!match[]then[true]else[false]] }}}/>

-e

2 Likes
7

I see, you are serving a single-HTML version, this is true.

I only use nodejs version now, so I get to be more cautious.

8

I’ve two node TW’s with public addresses.

One is private content, and behind an nginx reverse proxy with nginx enforced authentication (nginx also sets a cookie, and if you have the cookie, it skips auth). This lets me reach my private TW from my phone or laptop, no matter where I am, and 99% of the time those devices already have the cookie, so I don’t get bothered by auth either.

The other is public content (and I’ll be aiming for MWS down the track for it). For now, it’s protected from editing from TW’s own auth mechanism:

tiddlywiki . --listen credentials=users.csv "readers=(anon)" "writers=(authenticated)" "admin=nemo" port=8054 anon-username=anon

It’s then made public on a different port, via another reverse proxy, ensuring I get access logs. Visiting it’s URL without auth provides a read-only wiki for guests.

My understanding is that without the auth, it’s not susceptible to direct API attacks (I sure hope not, or I need to rethink a few things!)