Optional force automatic redirections to HTTPS if HTTP is used by mistake

[jweismann]

First off, let me use this opportunity to express my gratitude for all your hard work on this awesome project. Speaking of which, now that heroku has become the recommended platform for hosting, there is one thing that bothers me, namely that heroku doesn't support automatic redictions to HTTPS.

If one (by mistake) types HTTP in the URL or if HTTP happens to be the default choice of a given browser and one (again by mistake) doesn't pay attention then the site will be served via HTTP. For some this is fine. Personally, I would prefer either an error code or an automatic redirection to HTTPS. To the best of my knowledge this is not supported directly by the heroku platform so it has to be supported in the app itself. I guess something like this (in app.js) would serve the purpose and optionally support this behaviour:

 app.set('title', appInfo);
 app.enable('trust proxy'); // Allows req.secure test on heroku https connections.

• if (env.settings.isEnabled('httpsredirection')) {

•    console.info('Enabled httpsredirection: redirect http to https');
  

•   app.use((req, res, next) => {
  

•        if (req.header('x-forwarded-proto') !== 'https')
  

•            res.redirect(`https://${req.header('host')}${req.url}`)
  

•        else
  

•            next()
  

•    })
  

• }
  app.set('view engine', 'ejs');
  // this allows you to render .html files as templates in addition to .ejs
  app.engine('html', require('ejs').renderFile);

That is, if not enabled it work the same way as today, both http:// and https:// will work. If enabled all http:// requests will be directed to similar https:// requests.

Please let me know if you consider this relevant and thanks again for all your hard work on this project. We are many that are truly grateful for your efforts.

[jweismann]

Sorry for the missing code markup above. Hopefully this is more readable:

     app.set('title', appInfo);
     app.enable('trust proxy'); // Allows req.secure test on heroku https connections.
+    if (env.settings.isEnabled('httpsredirection')) {
+        console.info('Enabled httpsredirection: redirect http to https');
+       app.use((req, res, next) => {
+            if (req.header('x-forwarded-proto') !== 'https')
+                res.redirect(`https://${req.header('host')}${req.url}`)
+            else
+                next()
+        })
+    }
     app.set('view engine', 'ejs');
     // this allows you to render .html files as templates in addition to .ejs
     app.engine('html', require('ejs').renderFile);

[PieterGit]

@jweismann : this feature was on my wishlist as well. Can you try to create a pull request againt the dev branch instead of creating code in an issue? See https://openaps.readthedocs.io/en/latest/docs/Resources/my-first-pr.html or use a Git tool like SourceTree.

Some remarks about your implementation:

• Environment variables should be documented in the readme and are always be written in capital letters. I would prefer to use a INSECURE_USE_HTTP (default false). If set to true don't redirect. If not set or set to false we should redirect
• The solution should also work for non Heroku hostings. See also these lines
  

  cgm-remote-monitor/server.js

  Lines 39 to 51 in 7c272ec

  	function create (app) {
  	var transport = (env.ssl
  	? require('https') : require('http'));
  	if (env.ssl) {
  	return transport.createServer(env.ssl, app);
  	}
  	return transport.createServer(app);
  	}
  	require('./lib/server/bootevent')(env, language).boot(function booted (ctx) {
  	var app = require('./app')(env, ctx);
  	var server = create(app).listen(PORT, HOSTNAME);
  	console.log(translate('Listening on port'), PORT, HOSTNAME);

• We probably might also use request.secure for non Heroku environments, see https://jaketrent.com/post/https-redirect-node-heroku/

Optional extra's (can be in a different PR):

• also send hsts header, https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

[jweismann]

@PieterGit Sure - if you consider it relevant too, I will create a PR. I was just doing the code snippet to express the idea. This week is very busy for me but I would like to have it in the coming release. What's the deadline you are targeting ? As for testing of non-Heroku hosting, I might still have my azure account but beside that I only have access to heroku.

Finally, I like your idea of having redirections as default but this requires testing on non-Heroku hosting that I cannot commit to (besides azure, that is). We could play more safe and stick to the current situation as default and users would then have to make active changes to their settings to become exposes to this. Just a thought.

Thanks for your comments! I will dive on those when I prepare the PR.

[PieterGit]

@jweismann Others can help testing. Azure does not have Node 8.12.x yet, and there is not much interest in testing Azure and Azure often has issues. If there is no one stepping up to take ownership for Azure hosting of Nightscout and think we should decide to drop Azure support soon.

I think there are three possible deployments this future PR should be tested with:

1. Heroku
2. Node SSL based
3. With nginx or Apache in front of Node

I think @scottleibrand uses Apache in front of Node Nightscout, and I'm pretty sure he can help out on thinking what the best way is. Perhaps we should require front-end servers to set X-Forwarded-Proto to https starting from Nightscout 0.11.x

Yesterday I looked into upgrading the Node SSL to a Node http2 with Greenlock-express, see https://git.coolaj86.com/coolaj86/greenlock-express.js and https://git.coolaj86.com/coolaj86/greenlock-express.js/src/branch/master/examples/http2.js . That would not only take care of encryption but also on creating the Letencrypt SSL certificates.

I'm planning on doing a feature freeze at approx November 1st, but this is mainly my own goal. We should test 2-4 weeks with different configurations and I was hoping we could release 0.11 at approx December 1st.

[PieterGit]

This issue is outdated. See #4044 for more info and a PR.

[stavlor]

Hmm, I could be mistaken but I'm using an nginx infront of node setup and this doesn't affect API but appears to break the actual site in this config.

[stavlor]

Site just repeatedly does this

[daveewall]

I had the same problem. My server’s drive recently died, and I had to recreate my docker-compose images. When I did this, my Nightscout image rebulit with the latest node (which was easily fixed in the Dockerfile), but then with the right version of node, it built the new master branch, which was 0.11, and I got a redirect loop, despite going to https first (evidenced in chrome devtools). Both web browsers and the iOS app wouldn’t load. I had to downgrade back to 0.10.3 and rebuild the docker image to get it working again. Before downgrading, I tried setting the INSECURE_USE_HTTP to true, but the docker image still saw it as false, so I just downgraded so I can get back up and running.

That ENV part may be me forgetting to do something in docker-land properly, though. I’d have to re-test to be sure, but the docker instance log showed it as false when it spits out that info with the HSTS variable.