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 > > -- 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 [email protected]. To post to this group, send email to [email protected]. 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/2f866cd9-a588-4b09-b197-26f3d58f75a7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
