As per @BenLubar's suggestion, the commit 08cdfd2d601bbc77028ae634fb53fd2e7b8e0b70 introduces a one-character fix that now means sites will now require its express session cookie to be https only.
If you are terminating SSL via nginx, you will need to add the following to your nginx configuration:
proxy_set_header X-Forwarded-Proto $scheme;
If you are not using SSL, adding that line should have no adverse effects.
Closed via 08cdfd2d601bbc77028ae634fb53fd2e7b8e0b70
I'm using a hosted solution with nodeBB. I can't add this fix =( @julianlam what can I do?
Hi there, your instance should already have this fix applied. Are you seeing this issue on your forum?
I guess not. Thank you @julianlam
I am seeing this issue with Apache 2.4.x. Switching webservers is not really a practical option for me at the moment. Please can you advise how to set this header in Apache?
@codecowboy seems like it could be something like:
RequestHeader set X-Forwarded-Proto "https"
in your virtualhost config block.
source: http://stackoverflow.com/questions/18935448/https-scheme-lost-in-apache-proxy-scenario-upon-redirect-from-gitlab
Please try and let know if that works for you.
@jarey I dont actually have SSL set up at the moment? I'm not sure if that would make a difference? I get this if I try to add that line
Invalid command 'RequestHeader', perhaps misspelled or defined by a module not included in the server configuration
Action 'configtest' failed.
If you access your forum through HTTPS but your server handles internally as HTTP, e.g. if you use services like CloudFlare, the $scheme nginx will be passing is http when you want https. In this case, simply force it like this:
proxy_set_header X-Forwarded-Proto https;
Most helpful comment
If you access your forum through HTTPS but your server handles internally as HTTP, e.g. if you use services like CloudFlare, the
$schemenginx will be passing ishttpwhen you wanthttps. In this case, simply force it like this: