Authentication

[Jacqueline Mallette]

Background first. I'd like to use TiddlyWiki as a wiki for my project. Partly cooperative, but partly not. Thus would love to have some authentication of editors. There are some constraints - it will be run from arm device and limited thereof. So only JS remains at hand (also Python, Perl, shell) to make an auth proxy. Frankly speaking I just installed it on said arm (with MultiUser plugin using websockets), so have little knowledge of what is under the hood.
I thought about JWT token authentication - are there any ready solutions? (yes, searched the group).
Out of other solutions, I can split traffic to multiple interfaces, so only a set one would be editable (but how to make the other not editable? Disabling buttons does not disable requests).
Looking for suggestions.
I'm ok with JS, so with some guidance can develop solution on my own if needed.

[Jed Carty]

I am looking into adding authentication into the multi-user plugin but I haven't yet. JWT token authentication shouldn't be too difficult to add.

If you want to help with the multiuser plugin I would appreciate any help.

[Jacqueline Mallette]

On Saturday, December 30, 2017 at 2:32:00 PM UTC+1, Jed Carty wrote:

I am looking into adding authentication into the multi-user plugin but I haven't yet. JWT token authentication shouldn't be too difficult to add.

If you want to help with the multiuser plugin I would appreciate any help.

 

Sure. While I have little time now (before New Year), in few days I should be able to add some code. The only issue is I still have no idea how to block editing (based on some conditions). I'm fan of websockets :) .

[Jed Carty]

If you want to server the wiki and not allow editing of any tiddlers than we just need to make it ignore web socket messages from unauthenticated browsers (after we add some sort of authentication). The person would be able to edit the wiki in the browser but the changes wouldn't be saved anywhere. We could disable the editing buttons in the browser to make it more obvious.

If you want to allow editing some tiddlers and not others than we can also have that based on black or whitelists where the server only accepts updates for tiddlers that are listed (or rejects edits to tiddlers that are listed if a blacklist is used.).

I already have exclude lists set up that mark tiddlers that aren't synced between browsers. My plan is to extend that.

[Jacqueline Mallette]

Sure. I got this. But the issue to me is how can I prohibit editing on a backend side. I assume you know it already (I had even no time to seriously look into the code) thus I can help with jwt auth. Or any other asymetric encryption one. The rest will be yours.

[Jacqueline Mallette]

Jed,

I thought about where should I attach JWT. Should it be hook? I read your source now and as hooks emit events, attaching authentication there could make sense. Am I right?

[Jed Carty]

The normal flow for using JWT for authentication would be to get a token from the server and then send that with all the requests that require authentication. I haven't thought about it much but the easiest way to do it would probably be to make an authenticate message that, if the server accepts it, prompts the server to reply with a token that can then be used as the authorisation for changes.

[Jacqueline Mallette]

Yes, you're right. It can be even a separate class doing all the flow. However I'd love to know where to attach it to let you manage login state. Sole messaging I can simply glue to ws instance. Token string can be initially hardcoded. But as it's your plugin you know better where it's handier to push a response (athenticated/failed). On the node side the situation is similar.

[Jed Carty]

Ah, sorry. I was thinking of a different problem than what you are asking about. The lack of sunlight this time of year gets to me.

I haven't had a chance to think about the browser side of the authentication will be handled. I will look at it closer and send an email.

[Jacqueline Mallette]

Ok. looking forward.

On Thu, Jan 4, 2018 at 7:43 PM, Jed Carty <inmy...@gmail.com> wrote:

Ah, sorry. I was thinking of a different problem than what you are asking about. The lack of sunlight this time of year gets to me.

I haven't had a chance to think about the browser side of the authentication will be handled. I will look at it closer and send an email.

--
You received this message because you are subscribed to a topic in the Google Groups "TiddlyWiki" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tiddlywiki/tS1qzG9X9TM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tiddlywiki+unsubscribe@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/0a913410-4569-443e-90b3-81847254b701%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.