I have long dreamed of being able to host tiddlywiki on the internet with node. I recently got this working on top of a WHM/cpanel wholesale host, and am very excited, it performs well.
However this dream took no account of security. I now have a wiki online that anyone can edit and presumably add as many tiddlers as they want, perhaps even execute javascript as they wish.
I think I need to turn it off, but before I do can anyone suggest some security options, I would like it to provide read only unless authorised or inaccessible without a password.
Thanks
Tony
I do believe I can apply HTTPS/SSL easily but not sure how it relates to using high port numbers eg 60000 that works for me to access node.
• Independent of securing the wiki I have created a method by which to open a login tiddler at startup and provide the ability to select/create a user ID before proceeding,
• I was also investigating that on login it "decrypted a users tiddler" which then applied a whole set of "designed" preferences. In effect a profile, Toolbar button settings and more, One of these being an edit level 0 to 9.
• Then individual tiddlers could optionally have an edit level specified in the tiddler such that if it had an edit level of Five (5), only users with a 5 or less will be presented the edit button and a few other settings. This would allow one to, for example, stop system tiddlers being in inadvertently edited. If one was +2 from a given tiddlers edit value perhaps the content of the tiddler would be hidden.• Edit levels would even help me as a single user, for example hiding (a custom) edit button on a Viewer/reporting Tiddler when in fact my normal practice is to edit tiddlers in the viewer not edit the viewer itself.• Some may say this is security by obscurity but actually I was more interested in changing the functionality to suite a usage mode. I could even have multiple user ids such that I login with my dev user id (Every thing is stamped created by/Modified By) dev also allowing additions/changes by a given user to be listed exported etc... A user can also be equivalent to a usage mode. This may prove useful on top of Bob abd NoteSelf.• I would like to see encryption set such that the "owner" of the tiddler can decrypt it but they need not re-encrypt it because it will be re-encrypted with the original key automatically, perhaps using a logout sequence, this is also desirable for a whole of wiki encryption.
I have other user design ideas, which will all benefit from a user/password facility if the solution you are both looking at does not compromise these possibilities.
I am all for firm security being available, but In many cases TiddlyWikis are shared with trusted parties. If hosted on the internet, and we can confirm they are trusted parties that is great, but once they are in, the truth is that trusted team members may just want to have clearly defined options and edit-ability. User modes to guide them and the ability to classify tiddlers and set the author/editor reliably. Sure it can be hacked, but we do not always need to enforce restrictive security, just make functional user and access features available to that trusted audience.
I would also add there is value allowing a given user to maintain their own User based story list and History.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/b0213131-887c-4a7c-822f-35a63f47d2e8%40googlegroups.com.
Proxies generally provide the port number in an environment variable, which you can reference directly in the server/listen command. So "tiddlywiki mywiki --listen port:PORT” will listen on the port number given in the environment variable called “PORT”.
• Independent of securing the wiki I have created a method by which to open a login tiddler at startup and provide the ability to select/create a user ID before proceeding,OK so that’s something you can do in a standalone HTML wiki?
• I was also investigating that on login it "decrypted a users tiddler" which then applied a whole set of "designed" preferences. In effect a profile, Toolbar button settings and more, One of these being an edit level 0 to 9.• Then individual tiddlers could optionally have an edit level specified in the tiddler such that if it had an edit level of Five (5), only users with a 5 or less will be presented the edit button and a few other settings. This would allow one to, for example, stop system tiddlers being in inadvertently edited. If one was +2 from a given tiddlers edit value perhaps the content of the tiddler would be hidden.• Edit levels would even help me as a single user, for example hiding (a custom) edit button on a Viewer/reporting Tiddler when in fact my normal practice is to edit tiddlers in the viewer not edit the viewer itself.• Some may say this is security by obscurity but actually I was more interested in changing the functionality to suite a usage mode. I could even have multiple user ids such that I login with my dev user id (Every thing is stamped created by/Modified By) dev also allowing additions/changes by a given user to be listed exported etc... A user can also be equivalent to a usage mode. This may prove useful on top of Bob abd NoteSelf.• I would like to see encryption set such that the "owner" of the tiddler can decrypt it but they need not re-encrypt it because it will be re-encrypted with the original key automatically, perhaps using a logout sequence, this is also desirable for a whole of wiki encryption.
I think that all of the features you’ve mentioned are potentially useful, but I think that they could be kept pretty separate from the client-server work I’m doing at the moment. The component is concerned with how the server authenticates, authorizes and responds to HTTP requests. Authorization is done on a per-wiki basis, not per-tiddler. We may introduce TiddlyWeb’s concept of bags on the server, enabling more granular security configurations.
The connection with these features is that the new serverside stuff can provide the client wiki with a secure username in $:/status/UserName of the current user, which you can use as an alternative to the manual selection described in your first bullet point.
I have other user design ideas, which will all benefit from a user/password facility if the solution you are both looking at does not compromise these possibilities.Is the provision of the username sufficient for them?
I am all for firm security being available, but In many cases TiddlyWikis are shared with trusted parties. If hosted on the internet, and we can confirm they are trusted parties that is great, but once they are in, the truth is that trusted team members may just want to have clearly defined options and edit-ability. User modes to guide them and the ability to classify tiddlers and set the author/editor reliably. Sure it can be hacked, but we do not always need to enforce restrictive security, just make functional user and access features available to that trusted audience.I think you’re suggesting that it’s useful to have a “soft” layer of security that isn’t necessarily secure in the face of an adversarial attack, but can prevent people from accidentally doing the wrong thing. I’d agree wholeheartedly, but as I say, my focus right now is on the optional “hard” security layer between the client and the server on which that soft stuff can be built.