Hello everyone, I have posted a detailed procedure on this here ( http://di-sec.net/tw5ssl/tw5ssl.html). If Jeremy wants to include it in tiddlywiki.com, please feel free to do so, but I may have to add some more variants to this cert-based authentication later on. The topic is broader than I have originally thought.
Best regards to all, Pietro On Wed, Oct 2, 2019 at 11:59 AM Donald Coates <[email protected]> wrote: > Yes that is very odd!! maybe it has something to do with it being a > string in quotes?? Regardless congrats and I will most certainly file that > away in the old brain because I have no doubt I will do that very same > thing in the future!! > > > On Wed, Oct 2, 2019 at 2:01 AM Pietro Abano <[email protected]> wrote: > >> Hi Donald, >> >> thank you for your hint: I did not see the IP address there indeed. >> Obviously not good. >> >> So I was gonna try your suggestion (removing the Host $host parameter) >> but then I spotted my own typing error in the >> /etc/nginx/sites-enabled/default file. >> One would think the nginx would not start at all or at least warn me, >> because it checks the configs for syntax errors I guess, it happens all the >> time, but not this simple typo ("Ugrade" instead of "Upgrade"!) >> >> Everything works great now, the wiki is accessible only to clients with >> proper cert and its content is saved and updated accordingly. >> >> You simply made my date by making me go through this one more time. >> In case you'd want to see how it's done with client certs I can provide >> you (or anyone interested) with all the details. >> >> Thanks! >> >> Pietro >> >> >> On Wednesday, October 2, 2019 at 4:56:00 AM UTC+2, Donald Coates wrote: >>> >>> You'll probably get a better answer here but in the mean time: is >>> 192.168.112.110 the address that bob shows in the settings? On my own >>> setup I do not have proxy_set_header Host $host so I wonder if that is >>> causing the trouble. I believe that is for standard http connections and >>> not web socket. If you look here >>> <https://www.nginx.com/blog/websocket-nginx/> you will see that line is >>> not included. I still have trouble understanding the intricacies of nginx >>> and end up throwing shit against the wall until something sticks. >>> >>> On Tuesday, October 1, 2019 at 11:10:50 AM UTC-4, Pietro Abano wrote: >>>> >>>> Hello everyone, >>>> >>>> I could not find anything related to what I am trying to achieve here >>>> so if it's already covered somewhere please let me know. >>>> >>>> As much as I love Jed's amazing work on *BobWiki* because it changes >>>> the ball game for TW5 completely, allowing to share and work on something >>>> with a team, over a local network, there is one thing that I'm missing - >>>> user authentication. >>>> >>>> In my scenario it is not so much about who the actual individual is, >>>> only that it should be one of the authorized users. >>>> So I thought the client certificate-based authentication would do it. I >>>> set up a reverse proxy using nginx to handle SSL/TLS (for the web server >>>> and the clients) and talking to a local nodejs application on client's >>>> behalf. >>>> >>>> After some reading about nginx and tweaking my nginx configs I am >>>> finally able to access the TW5 on nodejs via https and even authenticate to >>>> it (actually to nginx) with client X.509 certs, but unfortunatelly I hit a >>>> problem: >>>> >>>> - can't make any changes to TW5/BobWiki over the https. >>>> >>>> >>>> The setup: >>>> the TW5 runs on nodejs at 127.0.0.1:8080 >>>> Tiddlywiki version 5.1.21 with Bob version 1.2.4 >>>> Serving on 127.0.0.1:8080 >>>> >>>> on the same host with IP of 192.168.112.110 there's nginx listening at >>>> 80 or 443 forwarding all traffic to http://127.0.0.1:8080 >>>> >>>> It appears the TW5 is not aware of any requests done from the web >>>> client, while direct connection to nodejs works as usual. >>>> >>>> Not being a web developer nor an experienced sysadmin (just a tinker) I >>>> have no clue as to where to look. Is it something with my nginx >>>> configuration, more specifically with websockets? When looking at the data >>>> being tranferred (Chrome, Inspect, Network) e.g. when adding a new tiddler, >>>> I don't see much going on. >>>> >>>> I can see some websocket communication initiated by >>>> $:/plugins/OokTech/Bob/BrowserWebSocketsSetup.js which is different >>>> when I go directly to nodejs - there I can see $:/core/module/saver in >>>> action, while when I use the nginx-proxied access I don't see this at all. >>>> >>>> Another symptom of the behavior is that when two users connect to the >>>> same TW5 on nodejs, they both see any changes done by one of them in almost >>>> real-time without refreshing the page while in ngix-proxied https access no >>>> such on-screen update happens. >>>> >>>> Studying the errors in Chrome I've come up with this which seems >>>> relevant: >>>> $:/plugins/OokTech/Bob/BrowserWebSocketsSetup.js:63 WebSocket >>>> connection to 'wss://192.168.112.110/' failed: Error during WebSocket >>>> handshake: Unexpected response code: 200 (of course without https, >>>> this looks like 'ws://192.168.112.110/') >>>> >>>> Btw, the Firefox's error pinpoints the line in the code (does not say >>>> which source, I assume it's this BrowserWebSocketsSetup.js): >>>> Firefox can’t establish a connection to the server at wss:// >>>> 192.168.112.110/. line 11345 > eval:63:48 >>>> >>>> This all happens regardless of http or https, it's the same error as >>>> long as nginx is in the middle. >>>> >>>> At various forums I found the solution for that Chrome error and it >>>> looks like a websocket configuration thing in nginx: >>>> >>>> - from https://github.com/websockets/ws/issues/979 >>>> >>>> "*Had the same issue, my app is behind nginx. Making these changes to >>>> my Nginx config removed the error.* >>>> >>>> *location / {* >>>> *proxy_pass http://localhost:8080 <http://localhost:8080>;* >>>> *proxy_http_version 1.1;* >>>> *proxy_set_header Upgrade $http_upgrade;* >>>> *proxy_set_header Connection "upgrade";* >>>> *proxy_set_header Host $host;* >>>> *}* >>>> " >>>> >>>> The same changes did not help in my case, so it must be somewhere else, >>>> maybe in the BobWiki code. >>>> >>>> But that's about all I can do about it so I'd need someone's help. >>>> Is there anyone here who would know where this comes from? >>>> >>>> I can provide him/her with all the configs or even the full VM >>>> (Ubuntu18.04mini) if needed. >>>> But the cert-based authentication seems to be too attractive for me to >>>> let it vanish to oblivion. >>>> >>>> All the best to the community! >>>> >>>> Pietro >>>> >>> -- >> 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/StoO3ApsWJU/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/tiddlywiki/07723a91-ad33-4449-a556-d411ddf95d75%40googlegroups.com >> <https://groups.google.com/d/msgid/tiddlywiki/07723a91-ad33-4449-a556-d411ddf95d75%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/tiddlywiki/CADZpJMy_htemJ5hY%2BMFyaARCrv8PvKh9HE2XEiUdHceAf4wN_w%40mail.gmail.com > <https://groups.google.com/d/msgid/tiddlywiki/CADZpJMy_htemJ5hY%2BMFyaARCrv8PvKh9HE2XEiUdHceAf4wN_w%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/CANbQO_D6dEo9W5ciV81UffOQjCOCsh9hjpHRELYoqmdh3dVY7g%40mail.gmail.com.
