Maybe dumb question..ha - https on node version tiddlywiki

[Ron Ropp]

Thought I followed the "using https" guidelines but it appears to be still only listening on 8080 and http. 

Does node version of Tiddlywiki need to be handled differently. I updated to 5.1.19 via npm update and everything else is pretty vanilla. (created the cert and key, etc) all on Linux and node 8.12.0

I also tried to use the port setting to 443 and that threw an error. 

My command matches the tiddlywiki page exactly, and it starts without an error but just http on 8080

Apologies if I am missing something obvious. 

Ron

[Scott Kingery]

I'm experimenting with this too and it isn't working for me either.

Using Windows, I have my tiddlywiki in a folder called mywiki.

csr.pem, key.pem and server.crt are ALL in the mywiki folder

using this command to start:

tiddlywiki mywiki --listen tlscert=server.crt tlskey=key.pem host=0.0.0.0 --verbose

I get:

Serving on http://0.0.0.0:8080

(press ctrl-C to exit)

Boot log:

  Startup task: load-modules

  Startup task: info after: load-modules before: startup

  Startup task: startup after: load-modules

  Startup task: story after: startup

  Startup task: commands platforms: node after: story

 syncer-server-filesystem: Dispatching 'save' task: $:/StoryList

 filesystem: Saved file C:\Users\skingery\OneDrive\TiddlyWikiNode\mywiki\tiddle

rs\$__StoryList.tid

So it is working on plain ol' http but not on https. Assuming I created the certs correctly, what am I missing?

tiddlywiki --version

5.1.19

[Scott Kingery]

Bump... anyone have thoughts on how to get this working?

[Dave]

try this: https://groups.google.com/forum/#!searchin/TiddlyWiki/0.0.0.0$20bob%7Csort:date/tiddlywiki/WtF6LPn7XE0/BPDd0UZsDQAJ

[Donald Coates]

I would think you need a web server to do this.  I run tiddlywiki node server and nginx in docker containers and use the nginx container to serve images and other files externally as well as provide https via letsencrypt.  I'm far from an expert on http and https protocol but I think browsers only communicate in https over a couple of ports: 443, 8443, and a couple others.

[Scott Kingery]

I discovered why the HTTPS instructions on Tiddlywiki.com don't work: https://tiddlywiki.com/#Using%20HTTPS

I've submitted this to github but here are the details:

The instructions as of now say to start the server like this:

tiddlywiki mywikifolder --listen username=joe password=bloggs tlskey=key.pem tlscert=server.crt

However, there are typos in the key.pm and server.crt commands. It should read:

tiddlywiki mywikifolder --listen username=joe password=bloggs tls-key=key.pem tls-cert=server.crt

This appears to work fine too for setting the port

tiddlywiki mywikifolder --listen username=joe password=bloggs tls-key=key.pem tls-cert=server.crt host=0.0.0.0 port=8081

[TonyM]

Ron, / Scott.

I see Scott solved this with his latest comment,  but I will share this anyway.

Some background but not a firm solution.

Since ssl/https was enabled for TiddlyWiki in an earlier version and I have SSL on my internet domain I can simply go to the address of my wiki with either http:// or https:// I am confident https:// is secure but I do not have a method to make tiddlywiki reject http:// only. The SSL feature and certificate etc is provided on my host.

As I understand it as node/tiddltwiki server is the host you need a method to configure ssl and the certs there, as documented (poorly) at https://tiddlywiki.com/#Using%20HTTPS

This is what scott is addressing.

Scott - Can you raise a gitHub issue to fix the typos, if in fact those files come with the tiddlywiki package?

Regards

Tony

[Ron Ropp]

Hey...this is great news, and I can confirm this works...its always the little things. This solves my use case nicely. I have a desktop and a laptop. I take the laptop to meetings and I can still connect wireless (and securely) to my tiddlywiki running on my desktop computer while taking notes in meetings and keep everything in sync. 

I resorted to using syncthing to keep two copies of tiddly between the two of them, which also seems to work and is secure, but of course I prefer to have all my communications secure even when talking to localhost :). 

Thanks Scott and Tony - good stuff. 

Ron