Hi Michael,
It is relatively easy to use TiddlyWiki through a remote HTTPS service, but it is important to distinguish the two following kinds of service, since TiddlyWiki has two different natures:
-
In its standalone file avatar, the standard way to serve a modifiable version of a TiddlyWiki file is through the WebDAV protocol: as Mark suggested, we recently had a thread on the Google group on this type of service. Many people in the community use WebDAV to serve their wikis so you should find more by searching the Google group.There is also a wiki document by Saq on using WebDAV with TW.
-
In the “Node.js” avatar, which is inherently modifiable, TiddlyWiki exists simultaneously in two forms: a web page in your browser, and a collection of files on the server host, maintained by a JavaScript application —tiddlywiki.js— fired by the Node.js server program. The code that resides in your browser discusses with tiddlywiki.js at the other end, in order to synchronise your local changes. Note that it currently doesn’t sync the other way round.
While the first form obviously needs an external server program (like rclone or nginx or apache) to be served remotely, the NodeJS form of TiddlyWiki is a full service by itself that can natively handle HTTPS. You can install it on your server host with npm install -g tiddlywiki. It doesn’t require any external server in order to do what you want. You’ll only need to first setup credentials as described here: https://tiddlywiki.com/#WebServer%20Authorization then create the HTTPS certificate and key files as described here: https://tiddlywiki.com/#Using%20HTTPS. Then you can run on your server host a command like:
tiddlywiki mywikifolder --listen “host=0.0.0.0:8998” “credentials=myusers.csv” “readers=(authenticated)” writers=mary “tls-cert=~/tls/server.crt” “tls-key=~/tls/key.pem”
That should be enough to serve TiddlyWiki on your local network through HTTPS with a reasonable level of security. If your local server host has the IP 192.168.1.3, then the wiki will be reachable at https://192.168.1.3:8998 . Note that the 0.0.0.0 notation is a convention to say that connections are accepted beyond the local host. This is not an actual IP address of any host anywhere.
At this stage, I should probably mention a variant of the Node.js tiddlywiki server that is called TiddlyServer. It has the advantage of being able to serve both the standalone and the Node.js form.
If you want to access your brand new service from outside your local network, you’ll need to connect to your gateway router and set a NAT rule that says that a request to a certain port of your gateway should be redirected to the local server host and port. For instance, if your gateway has the global address 185.199.108.153, and you set a rule that says that a request to 8997 should be redirected to your local server host (192.168.1.3) and port 8998, any connection to https://185.199.108.153:8997 from outside your network will get to your wiki.
Now you see the problem in the phrase any connection. If it works for you, it will work for thousands of bots cruising the Internet in search of an open door to get in. Most of them will give up after a few attempts, but some will insist; I don’t think there is a mechanism in TW that closes the connection after too many attempts. One thing to make sure of is to never launch tiddlywiki as root. If a bot gets in, at least it won’t be able to invade your system.
Another level of protection is to use a proxy HTTP(S) server. Typically using an Apache or NGINX server configured to further redirect connections to a running tiddlywiki. Note that this is a completely different setup than serving a standalone file as mentioned above. These very common HTTP(S) servers can also be configured to reject connections based on a variety of criteria. One of the advantages of these widespread tools is that Let’s Encrypt tools know how to automatically edit their configuration files and upgrade them to HTTPS, certified by Let’s Encrypt. With such a certificate, your browser won’t complain anymore that your service is self-signed.
It certainly would be nice to have a full HowTo for that proxying process applied to tiddlywiki, but I’m afraid it doesn’t exist yet. Maybe because opening a certified Node.js TiddlyWiki access outside a local network doesn’t really make sense before TiddlyWiki becomes natively multi-user? If you want to explore this route, have a look at the Bob variant.
–Xavier.