Support reverse proxies for URLs of resources, even with non-standard ports

[euklid]

Environment Setup

We have our parse server behind a reverse proxy (nginx) to deal with https, and a non-standard port. So when you hit https://some.company.com:12345/parse/ nginx redirects it to http://127.0.0.1:1337/parse on the local server. Currently, if a file should be fetched per request from parse server the middleware.js uses

var mount = req.protocol + '://' + req.get('host') + mountPath;

Because we have this behind a proxy we have used app.enable('trust proxy') in our express server that uses parse-server as sub application. This setting will be forwarded to the parse-serve app (See http://expressjs.com/en/4x/api.html#app.settings.table) so that req.protocol equals https and not http as it would without. Therefore we have X-Forwarded-Proto set to $scheme in nginx, that evaluates to https.
So this is fine.
But: req.get('host') reads directly the Host: field in the HTTP request and ignores that we are behind a proxy. Express states that using req.hostname will use the X-Forwarded-Host instead if app.enabled('trust proxy') === true (See http://expressjs.com/en/4x/api.html#req.hostname )

Therefore we changed the req.get('host') to req.hostname.
This still doesn't take care of the port. For this we added the following lines to middleware.js and configured nginx to send the correct port via X-Forwarded-Port:

var forwarded_port = req.get('X-Forwarded-Port');
var port = forwarded_port ? ":" + forwarded_port : ""; // if there's no forwarded port, don't add the port
// adjust mount
var mount = req.protocol + '://' + req.hostname + port + mountPath;

This solution works for us, so that we get correct responses to get the file at https://somecompany.com:12345/parse/files/someapp/random_string_name.file

Our question is: Was this the correct part of the code to modify? If not, where should we change it then? Do you have any other suggestions? We would like to help and create an appropriate pull request if you would approve of this suggestions.

[flovilmart]

I believe we're taking the problem the wrong way.
the mount variable was originally added to infer the location of the parse-server.

Now we have 2 extra variables

• serverURL, the local server URL for internal communications with cloudCode
• publicServerURL, the public server URL for forwarding the links to the user.

I can see that mount is used only in 2 cases:

1. in RestWrite, to generate the location header
2. in the Files adapter, to provide the full URL.

In both cases, this could be easily replaced by serverURL or publicServerURL.

What I would suggest:

1. keep the mount as it is
2. for the 2 explained use cases,add a small function in Config.js that would return the publicServerURL if set or the mount.
3. for your use case, I'll add publicServerURL as a launch parameter.

This will make less assumptions on the forwarded headers.
What do you think?

[euklid]

@flovilmart This issue should now be obsolete with #1287
Thank you very much for you contribution!

[flovilmart]

It should be please test if that fits your case :)