Improving TiddlyWiki 5 web server functionality

[Jeremy Ruston]

For the last couple of days I’ve been working on a major refactoring of the web server functionality of TiddlyWiki 5 — it’s the part that lets you access Node.js wikis from any browser. The work was motivated by consultancy work I’m engaged on, and builds on some initial work done by Devin Weaver back in 2016.

https://github.com/Jermolene/TiddlyWiki5/pull/2679

The improvements that are implemented so far include:

* Refactoring routes as separate modules, making it easier to extend the server with new functionality

* A new module for serving static file attachments over HTTP

* Adding support for authentication via a trusted header, making it easier to integrate with corporate single sign on (and Windows authentication)

* A new option for outputting additional debugging information

* Deprecating the existing “—server” command in favour of a new “—listen” command that uses a newly implemented command line feature for named parameters that can be specified in any order:

--listen host:1270.0.0.1 port:8080 pathPrefix:/Total

Improvements I’m currently working on:

* Adding support for multiple user credentials for basic authentication via a CSV file containing usernames/passwords

* Adding support for more fine grained authorisation (ie granting/denying individual users read/write permission to resources)

There’s quite a lot of significant new functionality, so I wanted to bring it up here because this is a good time for questions and suggestions.

(Just to clear, at this point I’m not planning to make any changes to the tiddlywebadaptor client that runs in the browser talking to the server; this round of work is just about enhancing the server).

Best wishes

Jeremy.

[Arlen Beiler]

Yay, this is something I have been looking forward to, although I was totally unaware you were actually doing it. The thought of setting up routes as modules has always intrigued me, although I have focused my energies elsewhere. 

--
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikide...@googlegroups.com.
To post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/953D329D-CFAC-455A-9DC1-336CB610BC45%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[@TiddlyTweeter]

Most welcome ...
 

[Jed Carty]

I fully support named parameters, I am always terrible with positional inputs. I keep trying to find a way that I could use some of what I made for the Bob plugin to help here and I am not sure that anything I did for the server I use with Bob is usable here.

[Andreas Hahn]

Dear Jeremy,

I also really welcome those changes and currently I mostly use the
server with a few routes that I added (serving attachments) to it
myself. I'll keep this short, but I definitely like the changes made
already and I look forward to having it be in the next version.

Here however are a suggestions that have come up for me in the past:

* CSRF protection for both the browser messaging (plugin library)
architecture as well as the PUT/DELETE rest api. It is scary to know
that iframes or any other website that I visit can inject javascript
tiddlers while running the server. This might work in tandem with the
new authentication.

(Hint: the plugin library architecture uses the cookie variable already,
but does not include/check for a nonce for some reason when getting a
response)

* A module (route) that serves rendered tiddlers, instead of serving
them as json. This is the unique ability of having the wiki run under
node and while possibly obscure, there is a lot of creative things one
can do with this with regards to browser integration (think
tampermonkey) or access to formatted data in the wiki from say bash or
other external programs.

* HTTPS support would be neat, not sure if its possible to include a
self signed certificate, but node's built in http(s) server is fully
able to serve over https as well.


Thank for tackling the server overhaul and also for reading,

/Andreas

[Jeremy Ruston]

Hi Andreas

* CSRF protection for both the browser messaging (plugin library) architecture as well as the PUT/DELETE rest api. It is scary to know that iframes or any other website that I visit can inject javascript tiddlers while running the server. This might work in tandem with the new authentication.

Good point. We might consider adding server-side support for CORS as part of the defences too.

The code is currently structured with two module types: authenticators and routes. I’m considering refactoring things to a single generic middleware module type that works along the lines of Express.js, which would make it easier to add such things.

(Hint: the plugin library architecture uses the cookie variable already, but does not include/check for a nonce for some reason when getting a response)

Can you point to the code you’re referring to here?

* A module (route) that serves rendered tiddlers, instead of serving them as json. This is the unique ability of having the wiki run under node and while possibly obscure, there is a lot of creative things one can do with this with regards to browser integration (think tampermonkey) or access to formatted data in the wiki from say bash or other external programs.

Yes, I did some experimentation with using the accept-header as part of the route matching parameters, I think it’s something I’d like to come back to.

* HTTPS support would be neat, not sure if its possible to include a self signed certificate, but node's built in http(s) server is fully able to serve over https as well.

Good idea. It looks easy enough from this SO answer:  https://stackoverflow.com/a/21809393

Thank for tackling the server overhaul and also for reading,

Thanks for the feedback. I’m tempted to look at the rendered routes and the HTTPS support but would be inclined to leave the CSRF stuff until later.

Best wishes

Jeremy

/Andreas

--
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikide...@googlegroups.com.
To post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/d9a8d4dc-ac1d-f535-9643-d68454bae30a%40googlemail.com.

[Kevin McShane]

I am just beginning using TiddlyWiki this year, but what I have seen has impressed me so far.  I am in the process of transitioning from a single file tiddlywiki on a shared network file to serving the wiki over node.js with Bob.  Two of the things you have mentioned are quite interesting to me, although I don't have much experience contributing to such a project.

These are the two items I am interested in:

* Adding support for authentication via a trusted header, making it easier to integrate with corporate single sign on (and Windows authentication)

I have looked into a few packages for my work.  NodeSSPI is attractive to me as one option because I work in an environment with Windows servers and VMs.

 

* Adding support for more fine grained authorisation (ie granting/denying individual users read/write permission to resources)

I think it would be nice to be able to organize users into groups for such permission also.

Is there anything I can do to assist in either of these areas?  If I'm way off-base, please also let me know as this is my first post to this group.

[Jeremy Ruston]

Hi Kevin

* Adding support for authentication via a trusted header, making it easier to integrate with corporate single sign on (and Windows authentication)

I have looked into a few packages for my work.  NodeSSPI is attractive to me as one option because I work in an environment with Windows servers and VMs.

NodeSSPI would require some custom integration to get it working inside TW5, but it certainly looks possible. I’ve been accomplishing something similar by running TW5 behind IIS and using a special rewrite module to make the Windows username available in a header: http://www.helicontech.com/isapi_rewrite/download.html

There are some instructions for setting things up behind IIS here:

https://tiddlywiki.com/prerelease/#Installing%20TiddlyWiki%20on%20Microsoft%20Internet%20Information%20Server

 

* Adding support for more fine grained authorisation (ie granting/denying individual users read/write permission to resources)

I think it would be nice to be able to organize users into groups for such permission also.

I do intend to add support for user groups with the built-in basic authentication module.

Is there anything I can do to assist in either of these areas?  If I'm way off-base, please also let me know as this is my first post to this group.

Thank you! Contributions are always welcome. In this particular case, this is quite a big change and so help with testing and documenting different configurations is likely to be very helpful,

Best wishes

Jeremy.

--
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikide...@googlegroups.com.
To post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/becfbb12-cb51-4680-bb0b-ff09eb3240cc%40googlegroups.com.

[Thomas Elmiger]

Hi Jeremy,

I just read the documentation as someone who never really tried node.js ... and I only noticed one tiny thing:

password=tset

... looks like a typing error to me ... maybe the password could also be someting completely different from the username (test) to make a good example. Maybe a passphrase like

password=LetMeIn

All the best,

Thomas

[TonyM]

Perhaps LetMeIn$#234

Because If I have used LetMeIn I expect that would be in a password list for hacking. :)

Regards

Tony