[TW5] http basic authentication support in Tiddlywiki (5)

[Lost Admin]

Is there a plugin, or some setting, that will tell TiddlyWiki to save to the "Server URL" using the HTTP basic authentication credentials if they exists? If so, could someone point me to it?

The problem I am experiencing is that if the password field is not set in the TiddlyWiki settings, TiddlyWiki attempts to save locally even though the Server URL is set-up. This is only an inconvenience for me but it would be nice if I didn't have to enter something into the Password field every time I use a new computer (or clear the forms cache) to save my wiki.


My TiddlyWiki resides on a web server running Apache. It is served through HTTPS and protected via HTTP Basic Auth. A few years ago I downloaded the store.php uploader script and made a few modifications to it (mostly around removing the authentication built into store.php). I did this because the web server already has HTTP Basic Auth set-up so it was a simple matter to control access to the tiddlers and store.php that way.


I realize this has turned TiddlyWiki into a multi-user web based wiki and I could use something like phpwiki instead but I only have 2 users (me and my brother). Besides, I like the convenience of being able to grab a single file and bring it with me when I'm going to be offline and want to update the wiki (then I can save the file back to the server when I get online again).

[Tobias Beer]

Hi Lost Admin,

Practically speaking, what do you imagine that plugin to do? Surely, you can't mean to store authentication credentials for your server in a way that everyone with half an hour of hacking lessons can either read or decrypt.

Of course, passwords are not persisted in the wiki as tiddlers. They shouldn't be visible as-is in the back-end, as is the case with store.php, but most of all, they should not be hidden in plain sight in the front-end either.

If I understand it right: basic auth means: log-in as often as the server tells you to and that's that.

Could you expand a little what these assertions practically mean:

My TiddlyWiki resides on a web server running Apache. It is served through HTTPS and protected via HTTP Basic Auth

I did this because the web server already has HTTP Basic Auth set-up so it was a simple matter to control access to the tiddlers and store.php that way. 

?

Also, did you perhaps wrote the opposite of what you meant to say here:

I realize this has turned TiddlyWiki into a multi-user web based wiki 

?

Best wishes,

Tobias. 

[Mark S.]

I think he means that he can set up .htaccess and have the file (usually the entire folder) protected by a password via the server's protection system.

Since the security is being provided by the server, he would like to hard-wire the password in the TW5 file so that he doesn't have to re-type it every time he goes on a new platform.

It's definitely not true that the TW5 is now multi-user. If he and his brother both submitted at the same time, someone's entry would lose.

Happy New Year,
Mark

[Dmitry Sokolov]

Dear All,

all info on the MultiUser feature is being collected here: MultiUser TiddlyWiki

Thank you for your ideas,
Dmitry

[Lost Admin]

It is as Tobias said. I am not using the password functionality of store.php at all. I pulled the entire password management functionality out of the php script.

But, if I just ignore the password in the Tiddlywiki, it won't save the page to the Url. Instead it tries to store locally.

If I set a password in Tiddlywiki, it overrides the one set by the browser in the header when it saves. Thus, I have to go into the Tiddlywiki settings and set the password instead of letting it use the one cached by the browser when I loaded the wiki.

As to multi-user Tiddlywiki, you are right about the risk of overwrite. I do have store.php do a check and send a warning if there is going to be a conflict using last modification time of the wiki file and a little bit of log analysis during save time. It isn't scaleable but works in a 2 user environment.