Node on the internet

[TonyM]

Hi all,

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

[Jeremy Ruston]

Hi Tony

I’m working on some changes to TW5’s built-in server functionality, see the discussion here:

https://groups.google.com/d/topic/tiddlywikidev/pOg-aiGtsPo/discussion

Amongst the changes will be the ability to run a wiki that is read-only for anonymous users and requires a login for editing. Credentials are still passed using Basic Authentication, and passwords are stored in plain text on the server. However, it should be OK for internet hosting as long as you put it behind HTTPS.

So, pending the new features, it’s probably worth spending some time exploring whether and how you can set up HTTPS.

If the primitive authentication support offered by the built-in server isn’t robust enough, then you can use an authenticated proxy server with decent user management (such as IIS or Apache). This is another new feature: you can specify an HTTP header that TW5 looks at for the authenticated username, and then write that header within the proxy.

Best wishes

Jeremy

> --
> You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
> To post to this group, send email to tiddl...@googlegroups.com.
> Visit this group at https://groups.google.com/group/tiddlywiki.
> To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/29eed46b-536b-41b4-bf89-3a69ec573c37%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Jed Carty]

I am actually working on this right now. I have a working node wiki up online using Bob so it is multi-user. There are still enough bugs that I am not going to announce it yet (shh! it's a secret!), but it works.

To make it work I made a new command so that the tiddlywiki component didn't run any server at all, it just boots as a module in a node process. The other node components run an express server that handles the authentication and paths.

[TonyM]

Thanks Jeremy/Jed for the directions you are taking,

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.

I have done a little work on the user component and may be able to add something if you are both still somewhat open to design ideas.

• 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 hope my humble contributions can be of value.

Regards

Tony

[TonyM]

I would also add there is value allowing a given user to maintain their own User based story list and History.

Regards

Tony

[Jeremy Ruston]

Hi Tony

On Thursday, June 28, 2018 at 10:35:23 AM UTC+10, TonyM wrote:

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.

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.

I would also add there is value allowing a given user to maintain their own User based story list and History.

Yes. A motivation for exploring the server side support for bags is for visitors to a wiki to have their viewing configuration (like story and history) saved to their own bag.

Best wishes

Jeremy.

Regards
Tony

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/b0213131-887c-4a7c-822f-35a63f47d2e8%40googlegroups.com.

[TonyM]

Jeremy,

I Think we are walking in the same direction if not on alternate paths. Some quick responses below.

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”.

Time for me to get into proxies for apps.

 

• 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?

Yes, Standalone and node served 

• 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 the retaining of keys and re-encryption is something to attend to for a secure approach in future. Demanding re-encrypt keys is setting up a "lost access nightmare".

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.

I agree, not only can they be separate but possibly should be seperate, however they need to maintain common standards, for example supporting a logout (performs actions) then triggers the client-server re-authentication process. 

Unfortunately I am not so clear on Bags.

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. 

This appears to be a low impact way to interface Auth with the internal wiki, I imagine it is overwritten, but then can be changed as an authorised user?

Can we determine inside tiddlywiki if the user has read only? or is anonymous?

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?

Yes the users name is sufficient for most cases, and your  comments reassure me that such authentication will not restrict these possibilities. 

If there is any additional information that can be passed in from the authentication process it could be helpful, especially if it is secure, since this is the security service we are using, the more the opportunity to manage security inside the Wiki. For example if an encryption key could be associated with the logging in user and passed to the Wiki.

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.

Yes, let me focus on the soft user security for now, I will watch your work with anticipation. 

Thanks

Tony