Server Issues when benig an Nginx Reverse Proxy

[ohare93]

@ohare93 , also, it's better to open a new issue for a new or only partially related problem. It helps to keep things simpler and I still get notified the same.

Originally posted by @Arlen22 in #72 (comment)

Alright here it is. Original comment:

I was having similar issues setting up authentication. This thread helped greatly, though it is rather finicky.

I am not getting the following error when I visit my TiddlyWiki externally (via a reverse nginx proxy). I did not get this error before applying this authentication 🤔

I do not get the error when visiting via local host, though the permissions are the same. Any idea how I can fix this?

Settings.json file:

{
  "tree": {
    "wiki":{
	"$element": "group",
	"$children":  {
	  "Personal": "tw/Personal",
	  "WikiFiles": "/home/pi/SyncThing/WikiFiles"
	},
	"$options": [{"$element": "auth", "authList": ["jmo"] } ]
    }
  },

  "bindInfo": {
    "localAddressPermissions": {
      "*": {
	  "datafolder": true,
	  "loginlink": true,
	  "mkdir": true,
	  "putsaver": true,
	  "registerNotice": true,
	  "transfer": false,
	  "upload": true,
	  "websockets": true,
	  "writeErrors": false,
	}
    },
    "bindWildcard": true
  },
  "putsaver": {
    "backupFolder": ""
  },
  "authAccounts": {
	"jmo": {
		"clientKeys": {
		  "jmo": { "publicKey": "<key>", "cookieSalt": "<mineral>" }
		}, 
		"permissions": {
			"datafolder": true,
			"loginlink": true,
			"mkdir": true,
			"putsaver": true,
			"registerNotice": true,
			"transfer": false,
			"upload": true,
			"websockets": true,
	  		"writeErrors": false,
		}
  	}
  },
  "authCookieAge": 864000,
  "$schema": "./tiddlyserver-2-2.schema.json",
}

Also, must I apply the permissions to a top level group? Or is there some way I can simply set it to the entire server? I do not like that people can get to the landing page to see even the top level group without signing in 😞

To which you had the good insight:

The other problem is probably related to some kind of cookie or method related problem related to reverse proxy. Check for failed network requests. Normally TiddlyWiki is not affected by TiddlyServer in this way, but in this case it is possible. Are there any errors in the server or browser console?

So I looked at the network of both localhost and the hosted version, and both are returning 404 on OPTION and HEADERS for their respective urls.

Localhost:

Hosted:

It doesn't seem to be the issue, as localhost is not experiencing anything abnormal. The only other differences I can see are that:

1. Localhost also fetches the HistoryList, whereas the Hosted version does not. No failed attempt, it just isn't there 🤔 this missing list could be what the error "Cannot read property 'indexOf' of null" is referring to".
2. CORS is enabled on the requests for the Hosted version No idea if this is somehow causing issues here, but I've been burned by it before! 😭 🤷

If there's any other info I can provide that could help anyone help me, just say the word 👍

[ohare93]

Aha, a discovery. I paused the code on the broken section of TiddlyWebAdaptor and found that is expecting the header Etag to be on the response for the StoryList. This is present on the Localhost version

HTTP/1.1 204 OK
Etag: "default/%24%3A%2FStoryList/83:"
Content-Type: text/plain
Date: Thu, 02 Jul 2020 08:06:28 GMT
Connection: keep-alive

But not on the Hosted version 🤔

Connection: keep-alive
Content-Type: text/plain
Date: Thu, 02 Jul 2020 08:08:21 GMT
Server: nginx/1.14.2

No idea where to go from here, but at least we know this is the error that is occurring. I suppose this is probably not the fault of TiddlyServer 😞 😅 any helpful advice appreciated, still

[Arlen22]

These links might help. The problem you're experiencing is related to NGINX reverse proxy. You normally need to set which headers get forwarded.

http://nginx.org/en/docs/http/ngx_http_proxy_module.html

http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass_header

[ohare93]

These links might help. The problem you're experiencing is related to NGINX reverse proxy. You normally need to set which headers get forwarded.

http://nginx.org/en/docs/http/ngx_http_proxy_module.html

http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass_header

Apologies for the late reply.

Those links were indeed helpful, but seem to link to an older version of nginx. This link was more useful https://nginx.org/en/docs/http/ngx_http_core_module.html#etag but in the end I still have not fixed this issue 😞 I have seen many instances of people exposing their TiddlyWiki to the world via an Nginx reverse proxy and Let's Encrypt for the SSL, and they seemed to have no problems with these headers disappearing. But none with TiddlyServer. I will try doing it without TiddlyServer tomorrow, and see what happens.

[ohare93]

Solved! Adding Etag required to the Putsaver (I did not see that option beforehand) got it working in an Incognito, and it turned out one of my extensions ClearUrls was removing Etag too! Double issue, but ll fixed now.

Thanks for the help mate.