Too many redirects when going to nightscout from any client

[renegadeandy]

I have been running nightscout stably for a long time on a RHEL 7.6 server.

I am not sure what has caused this, but now whenever I try to visit my nightscout host, the browser reports the error : ERR_TOO_MANY_REDIRECTS.

When I look at my browsers network connections, the browser is being spammed with HTTP 302 responses from express, by looking at the response headers I can see it has been given the 302 direction from express, therefore must be reaching the nodejs application, before the browser gives up. I see nothing abnormal in the running console after npm start.

I tried cloning the current master branch from scratch after running npm install i get:

[email protected] update-buster /home/andy/andyaps/cgm-remote-monitor

node bin/generateCacheBuster.js >tmp/cacheBusterToken

npm WARN [email protected] requires a peer of acorn@^6.0.0 but none is installed. You must install peer dependencies yourself.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

audited 6706 packages in 14.903s
found 3 vulnerabilities (1 low, 1 moderate, 1 high)
  run `npm audit fix` to fix them, or `npm audit` for details

So I run npm audit fix which gives:

[andy@192 cgm-remote-monitor]$ sudo npm audit fix
[sudo] password for andy: 
npm WARN [email protected] requires a peer of acorn@^6.0.0 but none is installed. You must install peer dependencies yourself.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

removed 1 package and updated 2 packages in 5.971s
fixed 2 of 3 vulnerabilities in 6706 scanned packages
  1 vulnerability required manual review and could not be updated

And then when I start the application I get normal startup messages, and after my browser gives up, I see no messages at all in the logs of the application.

I wonder if this is to do with npm or node itself, I installed a different version of npm 2 days ago....and this problem only started showing up after I restarted the running nightscout server. I was installing the server component of this project https://github.com/spacemeowx2/switch-lan-play/tree/master/server when i think it suggested i upgraded npm...which I did, but I can't believe that has caused this issue. I have since reinstalled both node and npm to no avail.

Can anybody help me debug what is causing these http 302 redirects? I am running the same master branch without issues on a seperate machine, suggesting that the problem is localised to the configuration of node, npm or a combination of all of the above.

I am running:
node version V8.15.1
npm version V6.4.1
RHEL 7.6

[xmizi]

"too many redirect" is caused by "new security setting" - all requests are redirecting to https by default. I have the same problem (https is managed by nginx.....)

try to set INSECURE_USE_HTTP=true in your NS configuration

[renegadeandy]

Hi @xmizi That has fixed it! It doesn't actually make sense to me, as I was coming in over HTTPS anyway...., as I was using express and let's encrypt to handle the ssl.

This new parameter looks bugged.

I say this because the flag says "INSECURE_USE_HTTP", yet I am actually using HTTPS, and even when I go to the site using http, I get an empty response (thank goodness). Can you explain what is going on here? This can't be the expected behaviour...

[PieterGit]

@xmizi @renegadeandy The "new security settings" are part of my improvements to make Nightscout secure by default. A lot of users were using Nightscout with plain http which is insecure. Only a few Nightscout users seem to use a reverse proxy (like Nginx, Apache, or Letsencrypt) to proxy TLS/https sessions to NodeJS Nightscout over http. From NodeJS backend point of view http traffic is insecure, therefore INSECURE_USE_HTTP. I agree that in hindsight that a name like REDIRECT_HTTP_TO_HTTPS (default to true) might be more appropriate, or we can make sure the INSECURE_USE_HTTP automatically detects insecure traffic in a robust way, like #4483

@renegadeandy About https://gitter.im/nightscout/public?at=5c94eab18126720abc25b6d4 . You're hosting Nightscout in an undocumented and unconventional way. Yet you expect us to fix your Nightscout issues immediately. Please try to minimize the amount of exclamation marks and ask for help politely. If you don't know you are using a https proxy, when you are, or randomly use npm audit fix, please read more documentation. In any case, make sure you can always revert to a working Nightscout (backup, revert to previous stable, etc).

We tried to get this behavior correctly for reverse proxies, see #4104 . I asked at Gitter for testing these configurations several times, but nobody responded. I asked people to document it several times, but nobody responded. Now that 0.11.1 has been released, you both complain that it's not implemented ok. Please be more gentle and start acting instead of complaining, e.g.

• document your Letsencrypt set-up with a PR in https://github.com/nightscout/cgm-remote-monitor/blob/dev/README.md
• add yourself to https://github.com/nightscout/cgm-remote-monitor/blob/dev/CONTRIBUTING.md#list-of-contributors for being a volunteer to test with a reverse proxy setup
• join the discussion or start contributing at cover non-Heroku secure requests in HTTPS redirect exemption #4483

[renegadeandy]

Hi @PieterGit You misinterpret my exclamations and tone! Apologies - and thanks for your work.

You are absolutely right, the by default state of nightscout on http was poor - I appreciate you taking effort to making the default to be to serve https.

There are however a couple of things I dont understand - and it may well be my ignorance.

I have setup SSL, by getting some let's encrypt certificates, and using these 3 environment variables, which I believe, Express nodejs looks at, and uses to serve an encrypted connection:

SSL_KEY
SSL_CA
SSL_CERT

You mention I am running nightscout, in an undocumented and unconvential way.

--I don't follow this. I am running the correct supported versions of npm, node, and am using 3 documented environment variables to serve HTTPS from the express server. Can you explain how you derive this conclusion?

--You also say i am using a reverse proxy. This again may be my ignorance, but I don't believe I am using a reverse proxy. I have no proxy server installed or running, I dont use nginx, I use nothing but npm start to run my nightscout, and it serves https connections.

I still don't follow the purpose of this new variable INSECURE_USE_HTTP. I think this works as follows:

If INSECURE_USE_HTTP == false then it will 302 redirect to an https connection if it can. If it is true, it will allow HTTP connections. The thing is, in my configuration, I have to have this variable set to true, despite that, NO HTTP connections work - express mandates because of the 3 environment variables, that I speak to the server using nothing but HTTPS, which means that this parameter or the logic behind it, is currently not integrating these 3 variables into its checks.

Am I making sense here?

[jweismann]

@renegadeandy The variable name INSECURE_USE_HTTP is very confusing, especially in non-heroku deploys. What it really means is whether or not HTTP requests should be redirected to HTTPS requests. In a pure HTTPS setup there are no need for redirections and hence one wishes to avoid redirections and must set INSECURE_USE_HTTP to true. Admitted, this is very confusing and I suggest that the name of this config variable is changed.

[jweismann]

@renegadeandy or more specific whether or not requests should be redirected to HTTPS.

[renegadeandy]

Hi @jweismann I am pleased you agree here. The variable should almost be:
SSL_SETUP_MANUALLY=YES
Where if it is NO the work that @PieterGit has done will make the appropriate changes to deliver https?