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 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/05b65256-b203-43fd-9809-098ea6bdbb18%40googlegroups.com.
