Advanced authentication

[newhinton]

Currently only basic authentication and setting a header are the only way to authenticate a user. I think we could build a ui for that, so that a user can use password manager or similar. I have experimented with the basic.js to serve a html webpage and then redirect the user to a site using the user:pass@domain.tld scheme, but that promts a browser popup (which is exactly what i do not want)

So, my idea would be to create the ability to set a session variable or something similar server side, so that we can call a route and pass the password and username to some sort of backend-plugin that then authenticates a user (that would also allow for many different methods of authentication since we then can create plugins that add eg. ldap).

Any ideas or suggestions on this topic?

[AnthonyMuscio]

A Key part of this is to allow a user to take ownership of the wiki, check it out for edit, check it back so someone else can edit. this requires consideration of single file wiki saves.

I have done some experimental work on this but do not have the js and plugin dev skills, local and session storage is already available and a great place to maintain session authentication information.

Regards Tony

[newhinton]

@AnthonyMuscio I have since my original post made further progress with migrating from http-header authentication to cookiebased authentication which looks promising. The main problem i am facing in my prototype is the server-side, i have not yet figured out how to store a session-information.

Do you know how to do that and can you provide me with hints on where i can find the session store?

Regarding your first comment, if i undestand you correctly that should not be an issue. The basic authentication is more or less only for the nodejs version which runs as a server, not for single file wiki's

[AnthonyMuscio]

Hinton

I am no expert on this. In what server environment are you doing this or want to? Are you saying you only want a similtaniouse edit on a folder based wiki?

I have been exploring php user authentication and single file wikis. However this has led me down the path of the local storage plugin in the new release and access to local rather than only session based storage.

I have made a number discoveries of late such as the passwordwidget already saves in the browser session. I believe with a checkin/out process and the ability to store changes until the users access permits and then commit changes I have a solution.

The other key is using a php based user login and auth process and reloading the wiki with auth detail fed into the wiki. Within php you can set and interogate server session info the logged in user cant see.

Any way. This is early in my journey

Tony

[newhinton]

@AnthonyMuscio Thank you for your input! But i think we are talking about two different things, it seems you mostly mean the html/standalone/file -version of tiddlywiki, whereas i am talking about the nodejs-version of tiddlywiki. They both need different ways of authenticating, and with php you are on the right track.

However, that is not the way i need to do it. I wish you success on your way to build your own tiddlywiki! :D

[sukima]

Why not use a proxy? Have an NGINX rule or Apache setup that denies access to the Node.js server/port or Single HTML or PHP script unless the user has a session cookie. This way if they are not logged in they are redirected to a login page, cookie gets set and NGINX sees the cookie and allows the request to be proxied to the Node.JS TiddlyWiki or static HTML file.

[newhinton]

Because that is extremely complicated to setup and maintain (at least in comparison to my current prototype). Since you are authenticating tiddlywiki, it should take care of the authentication, and not apache or nginx or the proxy.

Also, you introduce a second layer of configuration, you already need to tell tw about read/write permissions anyway, so just setting --uiauth (or similar) is really the way to go and much easier

[AnthonyMuscio]

Hinton,

Thank you for your input! But i think we are talking about two different things, it seems you mostly mean the html/standalone/file -version of tiddlywiki, whereas i am talking about the nodejs-version of tiddlywiki.

That is why I asked you to tell me on which server.

Since you are on the node JS platform I presume you have looked at Bob for multi-user and Multi-access services. I believe Jed has developed his own secure online wiki environments.

Also, Like in your second paragraph, I believe the final solution if developed well would allow a "plugin" authentication process which has alternatives for the different server environments. Some of my methods, within the wiki (rather than the server) may very well apply to nodejs as well.

In other discussions it was stated that using a proxy was the only way to ensure a strong level of security. But configuring proxies is unknown to some of us, and appears somewhat complex.

Best of luck in your endeavours.

Tony

[sukima]

I still feel rendering a login form, maintaining an authorization mechanism, cookie management, etc. is out of scope for TiddlyWiki. Especially when it is so easy to boot up a tiddlywiki service from any Node script.

[newhinton]

My prototype is not much more complex than the basic auth version, the main culprit is the handling of the credentials. While basic auth is cached (and subsequently purged by the browser)cookies are not. Therefore we need to give the client a token that is valid for a given time. That is basically the most complex thing, and given the huge benefit above basic auth, it is worth the (minimal) effort of maintaining this code. Especially given that this is highly similar to the basic auth code AND the huge improvement in ui/ux (basic auth is just aweful, you are intercepted by an popup, it looks ugly and you cant even use password manager)

Especially when it is so easy to boot up a tiddlywiki service from any Node script.

I dont see the connection to an ui-login, can you explain?

[sukima]

Your PR is doing exactly what I suggest but relies on modifying the core code instead of layering on top of it.

It is my opinion that this is out of scope for TiddlyWiki itself and is better suited as a TW plugin or a layer over the booting of TW.

For example a simple server.js could proxy to TW.

const $tw = require('tiddlywiki').TiddlyWiki();
$tw.boot.argv = ['./', '--server'];
$tw.boot.boot();

http.createServer(function(req, res) {
  if (checkAuthorization(req)) {
    proxy.web(req, res, { target: 'http://127.0.0.1:8080' });
  } else {
    renderLoginPage(req, res);
  }
}).listen(8888);

All I'm saying is that this feels like a lot of work for a feature that isn't really a TW feature but more a custom plugin or alternative boot script.

Then again maybe other feel differently. I personally think if this were a plugin it would be far more useful.

[newhinton]

Ah now i get what you are trying to tell me

Yes, currently it modifies the core code. What i hope to achieve in my pull request when it is finished is one of two things: a) provide a authentication method which modifies the core code (but does not override basic auth!) . The user should be able to enable this method via parameter, something like --uiauth (or maybe even be the defaullt with a switch for basic auht)

or b) a tiddler which users can import, and then this tiddler provides all the nessessary bits and pieces to make this work

i would be fine with either one, but i started with implementing it in the way of a because that is what i new how to do.

I am open to suggestsions on how to build this in tiddler form, but since this is quiet important server code, i am not sure if it is even possible

I can see your reason behind arguing that tiddlywiki was never meant to be running as a server, but only as a local wiki, and therefore it now does not need to provide authentication methods, but i think while it is not tw's job to provide a big complicated user management or anything like that, the shift to a nodejs application as a server now requires some way for authentication, and the server provides that currently in the form of badic auth, and token based header authentication. Its not far off to provide a ui method

but i guess we'll see what others have to say about this, and maybe this whole discussion is useless because there is an easy way that modularizes this code which i don't know about yet :D

[sukima]

Hmmm. So I actually tried this after your comment. My original idea of proxying TiddlyWiki does work but is complicated (I was unable to find a simple tool for this). I then thought to look into a TW plugin and realized that although TW has a modular authentication system it is hard coded to the first one it loads.

I think the problem you ran into is that TW has some implementation bugs that would prevent you from developing your own modular plugin for authentication without changing some core code.

I think it would be helpful to document these restrictions and work towards making the authentication system more accessible to plugin authors so that you could have your own authentication mechanism separate from the core.

[AnthonyMuscio]

It would be great if appropriate and alternative authentication methods were available as are alternate savers. The trick is to control access in the source of truth wiki but if permitted and the wiki is downloaded let new authentication apply. However being able to maintain user identity in the new wiki is desirable, especialy with createdby and modifiedby providing tiddler level authorship.

Regards Tony

[AnthonyMuscio]

It would be great if appropriate and alternative authentication methods were available as are alternate savers. The trick is to control access in the source of truth wiki but if permitted and the wiki is downloaded let new authentication apply. However being able to maintain user identity in the new wiki is desirable, especialy with createdby and modifiedby providing tiddler level authorship.

Regards Tony

[Jermolene]

Thanks @newhinton I'd concur with @sukima that the best outcome here would be to refactor the core as required to make it practical to have custom authorisation plugins, and then have a cookie based reference implementation in the core plugin library.