Like TiddlySpot but using https.

412 views
Skip to first unread message

Lost Admin

unread,
Mar 14, 2017, 8:17:10 PM3/14/17
to TiddlyWiki
Hi all,

I'm working on a place to store tiddlywikis on the web similar to tiddlyspot.com except mine is going to use the https transport layer.

I've got a bare minimum setup (think early alpha or proof of concept).

Anyhow, I'm not really announcing it at this time, I've got a question.

The default when you save online is tiddlyspot.com (for obvious reasons). And for (hopefully equally obvious reasons), I would like to have the initial empty template I provide during setup to default to my site. I think I can modify the core enough to do that by editing 3 system tiddlers:

$:/languate/ControlPanel/Saving/TiddlySpot/Hint
$:/language/ControlPanel/Saving/TiddlySpot/Description
$:/core/modules/savers/upload.js

Is there an easier way? Maybe a single tiddler that defines the default?


You won't have to use my template with my site. Just like tiddlyspot, you can use whatever starting point you want. I'm only planning on putting an initial empty wiki there for ease of use.

It will be https only. If you try http, it will redirect you to the https site (this already works).

For SSL certificate reasons it will be https://wiki.<domain>.<dom>/<wikiname>(/index.html)

I don't want to compete with TiddlySpot, I just want TLS and if I'm going to the trouble of making it for myself, I may as well let everyone play.

Sven Wetzel

unread,
Mar 15, 2017, 2:23:09 AM3/15/17
to tiddl...@googlegroups.com

Hi Lost Admin,

do you looked over to my plugin/storephp? https://quaraman.de/tw/storephp.html it can be used to have it run under ssl.

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@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/cfbe4e4c-d487-40a8-9dbe-072436df3440%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Lost Admin

unread,
Mar 16, 2017, 8:32:28 AM3/16/17
to TiddlyWiki
Other than the official TiddlyWiki (empty.html from TiddlyWiki.com) are there any other current wiki templates that I should think about including?

Is anyone interested in playing beta-tester?

Before I go public, I've got two more items on my must-have list:

1) encrypt the passwords in the password database.

2) re-do the internal structure for storing wikis (I just don't like it as it sits now).

And on the should-have list:

1) Give people the ability to change their password

2) Give people the ability to delete their account

3) Give people the ability to re-set their wiki (basically delete and re-sign-up in one shot)


On, and one last question. Does anyone actually care?

Mat

unread,
Mar 16, 2017, 3:56:13 PM3/16/17
to TiddlyWiki
Hello Lost Admin!

I'm not sure I understand - is your intention to create a service like more or less exactly like TiddlySpot, but with https?

...and to run it like cousins Simon and Daniel Bard do with TiddlySpot is run, i.e public, free, reliable etc????

That would be incredibly generous. But I must assume I misunderstand something because that would be quite a moral commitment considering how people truly rely on TiddlySpot. Of course, your project is interesting even if do, in deed, misunderstand your intention! ;-) ;-)

So, if I may, exactly what *is* you intention?

Thanks!

<:-)

Lost Admin

unread,
Mar 17, 2017, 8:59:52 AM3/17/17
to tiddl...@googlegroups.com
Hi Mat,

I can't say it will be exactly like TiddlySpot. I don't know what all they do in the back-end. I would hope it turns out as reliable as TiddlySpot, but I'm not sure I can live up to their proven track record.

Plus, wikis will be at https://wiki.<domain>/wikiname

What I am planning is that it will be public, it will be free up to the capacity of the VPS I'm running it on. I can only hope it will be sufficiently reliable since I plan on using it myself.

I'm making it because of 2 concerns I have with the lack of ssl on TiddlySpot. 

First, the tiddlywiki credentials are passed over the Internet unencrypted, which is not a good idea. Using HTTPS solves that. 

Secondly, the various store.php scripts I've found use plain text password storage. I don't know if that includes the variant that TiddlySpot uses. I plan to fix that on my version this weekend and  store the passwords using the same encryption supported by the lighttpd server for basic authentication.

I have already paid for a tiny VPS from Liteserver.nl for a year (the really small 256 MB of RAM one). It's setup with Debian Linux, Lighttpd, and php5. The SSL certificate is provided by Let's Encrypt. The current domain is my personal domain.

I plan on moving one of the wikis I have on TiddlySpot over to my own system once I'm happy with the setup and stability. I have 2 wikis on tiddlyspot, the other one will stay there.

In terms of features that I feel are needed (on my system) for it to be considered ready for public access:

* https only for accessing the wikis (done)
* wiki user's passwords will be stored in a secure manner (crypt encrypted or apache digest auth (salted MD5).
* each wiki in it's own directory, including a backup directory (backups beyond a certain age will be purged) (done)
* a sign-up page (done)
* a user control area where the wiki owner can change his/her password or cancel his/her account
* limit on size of wiki (this is a php upload setting, currently 8MB but I may change it depending on performance, probably not smaller).

Right now I lack the encrypted password storage and the user control panel.

After that I hope to add:

* A selection of template wikis to choose from during account creation (like TiddlySpot).
* Support for multiple wiki users of a single wiki (managed by the wiki owner).
* Option for a wiki owner to request a zip file of their wiki and all saved backups.
* Option for wiki owners to generate a static version of their wiki (similar to tiddlywiki/static) if I can ever figure out how to get node.js to do that.
* A pretty list of hosted wikis, being added to the list is at wiki owner's choice, it will be opt-in if it ever happens.

Jeremy Ruston

unread,
Mar 17, 2017, 9:18:41 AM3/17/17
to tiddl...@googlegroups.com
Hi Lost Admin

Terrific, very pleased that you’re doing this. The idea of doing something for yourself but making the spare capacity available for others is pretty sweet.

Your ideas for extending TiddlySpot make good sense, and I’m sure would meet the needs of many people.

One radical possibility you might want to look at is to switch from using TiddlySpot's custom HTTP POST for saving to using the standard WebDAV saver (which is very similar). The advantage is that the WebDAV saver can detect if the file has been saved by someone else on the server, which is very handy in multi-user situations. Either way, it’s obviously beneficial for users if you can use one of the built-in core savers, and avoid requiring a custom one.

* Option for wiki owners to generate a static version of their wiki (similar to tiddlywiki/static) if I can ever figure out how to get node.js to do that.

We can help you with that.

Best wishes

Jeremy

* A pretty list of hosted wikis, being added to the list is at wiki owner's choice, it will be opt-in if it ever happens.

On Thursday, March 16, 2017 at 3:56:13 PM UTC-4, Mat wrote:
Hello Lost Admin!

I'm not sure I understand - is your intention to create a service like more or less exactly like TiddlySpot, but with https?

...and to run it like cousins Simon and Daniel Bard do with TiddlySpot is run, i.e public, free, reliable etc????

That would be incredibly generous. But I must assume I misunderstand something because that would be quite a moral commitment considering how people truly rely on TiddlySpot. Of course, your project is interesting even if do, in deed, misunderstand your intention! ;-) ;-)

So, if I may, exactly what *is* you intention?

Thanks!

<:-)

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

Lost Admin

unread,
Mar 17, 2017, 9:34:28 AM3/17/17
to TiddlyWiki
Re: WebDAV

I looked into that. My initial plan was to run my own personal 'cloud storage' server with WebDAV but by the time I got all the bits and pieces I wanted together I had blown out the memory limits on my very inexpensive VPS (at 7.50 euros per quarter, it's hard to beat). I may look again in the future.

Re: static site generation,

In agile terminology, that is on my could-have list. When it moves up, I'll ask.

P.S.

the site, domain, and functionality almost up to tiddlyspot are in-place and function (I've only done basic functional testing). I haven't told people the domain/website because there are some things I want to change that might require wiping out the content (and user database). But, if there are people who want to be testers, let me know and I'll e-mail you the current url.

I expect testers to try to break the functionality and provide me with detailed instructions on how to duplicate the breakage (along with accurate to-the-second time and time-zone that they broke it and their source IP address so I can check logs). Also, things like fixing my grammar and spelling, or pointing out errors or omissions in documentation (when I get around to making it).

Stress testing is not needed. I'm fully aware that with the size of VPS I'm using, concurrent connectivity is going to be limited.

Lost Admin

unread,
Mar 20, 2017, 11:59:06 AM3/20/17
to TiddlyWiki
Status Update on my https project

Hopefully I'm not wasting people's time with this post. 

Instead of spending the weekend making modifications to store.php (to support a more secure password file) and some behind the scenes re-configuring of the web server, I decided to have another look at Jeremy's suggestion of using WebDAV for saving.

My initial plan with the VM was to set-up OwnCloud (and hosting my own tiddlywiki was incidental to that). I abandoned that plan because of the memory requirements of OwnCloud (I wasn't willing to pay for a VM with enough RAM). However, just implemeting the WebDAV module of Lighttpd is a different story.

So, I spent a chunk of the weekend re-building my set-up to do that. It works pretty well. Unfortunately it leads to some security issues I'm not ready to deal with in a multi-user environment. There is no built-in way (that I found) to limit the files that could be uploaded (I found some ways to limit per-file size but not per-user size, file names, or file types). This opens up a problem where it is far too easy for a malicious user to host nasty things if they find it. It also added a lot of complexity in setting-up individual repositories with the features I want. I may re-visit WebDAV in the future as I think these things are resolvable, just not in a weekend (at least not by me).

I did manage to swap out password management in store.php such that the back-end file now uses the same file format as Apache digest authentication (which is also used by Lighttpd). This doesn't involve changes to TiddlyWiki, so it is still transmitting the password in clear between the browser and the server. Only the back-end no longer stores passwords in clear text. Unfortunately, the WebDAV experiments left the web server all messed up and I didn't have time to clean things up to be usable.

I do think that long-term WebDAV is still the way I want to go. I just need to figure out how to introduce appropriate logic to better control and separate users.

Sven Wetzel

unread,
Mar 22, 2017, 2:00:26 AM3/22/17
to tiddl...@googlegroups.com

Hi Lost Admin,

when I understood it right, the webdav protocol gives the control of user rights to the file system that is used to host the files.
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

Lost Admin

unread,
Mar 22, 2017, 9:48:41 AM3/22/17
to TiddlyWiki
Yep, and therein lies my problem.

Instead of having a user management system built-in to the web server (basic-auth) and/or server side scripts (store.php), I have to re-build the entire sign-up system to create local user accounts for everyone (to get per-user storage limits) and update the web server configuration to support each new user's sub-directory with proper authentication and access control. A vastly different security model with much higher impact in the event of a remote-code execution vulnerability.

If I switch to Apache (instead of lighttpd), I would be able to create custom handlers for the input methods which could then support managing per-user storage limits. But the way Apache works, it would significantly increase memory usage for more than a couple of simultaneous users.

Lost Admin

unread,
May 31, 2017, 11:38:14 AM5/31/17
to TiddlyWiki
Sadly, I must say that for technical reasons, I will not be able to make my TLS enabled place for tiddlywiki storage available.

I've pretty much got all the added layers of security I wanted working in my test environment (jail on home computer) but it uses more memory than the VPS has and at this time I'm not prepared to pay the extra.

I will try and figure out github so I can offer patches to store.php that will allow others to take advantage of hashing passwords in the config file.

On Friday, March 17, 2017 at 9:18:41 AM UTC-4, Jeremy Ruston wrote:
Reply all
Reply to author
Forward
0 new messages