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
On Wednesday, June 27, 2018 at 7:53:10 PM UTC+10, Jeremy Ruston wrote:
>
> 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
>
>
>
> > On 27 Jun 2018, at 10:30, TonyM <[email protected] <javascript:>>
> wrote:
> >
> > 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
> >
> > --
> > 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] <javascript:>.
> > To post to this group, send email to [email protected]
> <javascript:>.
> > 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.
>
>
--
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/1858896e-40ea-441d-bbb2-9d6e7a071c6c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
