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.
