Added HTTPS Check for Heroku

[Nickster28]

(Thanks to http://jaketrent.com/post/https-redirect-node-heroku/)
When hosting on Heroku, it turns out the request.secure will always be false, even if the client requests over HTTPS. Instead, Heroku adds an HTTP header 'x-forwarded-proto' specifying the protocol used ('http' or 'https'). For those on Heroku, this additional check will allow the HTTPs check to work. For those not on Heroku (where this header doesn't exist), it won't do anything.

[ghost]

By analyzing the blame information on this pull request, we identified @flovilmart, @deada92 and @felipemobile to be potential reviewers.

[ghost]

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at [email protected]. Thanks!

[drew-gross]

This should only be done when running behind a trusted proxy, otherwise anybody could include that header and trick the dashboard into thinking it was using HTTPS. Can you change this to only trust the header if the user specifies that they want to trust it?

Also, instead of checking the header directly, you can use app.enable("trust proxy")? That does the same thing but is more robust and also takes care of the other X-Forwarded- headers.

[ghost]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

[joeyslack]

Great fix! This resolved my issue hosting a dashboard on https on Heroku. Without it, it's impossible to host a dashboard and parse server in the same app, using the piggyback ssl cert.

[flovilmart]

@joeyslack you should use either set('trust proxy', true) or allowInsecureHTTP but trusting X-Forwarded-Proto is bad is a general case as anyone can set that header and your server will gladly respond over HTTP.

[Nickster28]

@joeyslack @drew-gross @flovilmart Take a look at my followup pull request, which addresses these issues: #535