Authentication

[tobibeer]

How would a TiddlyWiki sync adapter do that? You'd need some user-management, unless you were fine using htaccess?

[Wheels00]

True. Tiddly web does that. Htaccess seems ok. I'm also toying with just using a random folder name and ensuring the saveTiddler.php can't be used to upload executables or large files.

Or perhaps some sort of challenge from the server and response from the wiki, hashing a key with your user name and the challenge string.

I don't know really

[tobibeer]

@Wheels00, perhaps there's some code to learn from that will only just be available for testing live on TiddlySpace for another 2 months?

@cdent: Any pointers where to find what?

[cdent]

@tobibeer I'm not clear on what you're actually looking for. Can you expand a bit and then maybe I can point at some examples?

[tobibeer]

@cdent, I know it's perhaps a bit of a stretch, but the task at hand would be how a php based server-side syncer implementation for TW5 could be extended so as to provide a basic means of authentication (not necessarily user management). On TiddlySpace we have that login popup in the top-right corner... and all the bells and whistles that ensure you're logged in.

Of course, there'd have to be a general discussion first as to what a login does: provide access to the full thing? (that could already be achieved via .htaccess). So at this point it would probably mean: allow write access.

It's not necessarily about the exact code at this stage but more about an architectural draft and some reference components to learn from.

[cdent]

The underpinnings of most of the auth solutions in tiddlyspace and tiddlyweb is that there is some process (often but not always a web form) which takes some information (often a username and password) and validates it. If it is valid a Set-Cookie is returned to the browser. In subsequent requests the cookie is sent in every request to the server and used to identify the requestor. To avoid people being able to hijack cookies, they are usually encrypted and encoded in various ways.

When the server gets the cookie it turns it into a user and in the various read and write operations you check to see if that user can do that. This allows for the capability where someone might be able to read a tiddler but not write it.

As @Wheels00 says above, all that might be overkill. If all that's really required is making it so only some people can access the syncer and the tiddlers it is hosting then an .htaccess file guarding the php files with at least one username and password managed by htpasswd (is that still a thing?) could be sufficient.

[tobibeer]

One way to go about separating read from write access in fact appears to be to have two wikis.

1. one for r/w with the full syncer, sercured via htaccess and
2. another which — not sure if it would require a syncer or something else — serves the tid files to some index.html wiki, loads them from there, or bakes them into that, which would be unable to do any syncing back to the server

However, that would mean that your syncer scripts will need some strong restrictions as to what precise location a wiki must be at in order to be allowed to talk to them.