How to use MongoDB Charts with Nginx reverse proxy ?

[François Lecomte]

Hello,

I try to configure my nginx to proxy requests for MongoDB Charts to the docker container, but it doesn´t work.

When I query for example: http://myserverip/mongocharts,

it returns index.html file, but then it tries to get the files vendor.css, index.js etc... from the root path http://myserverip/index.js instead of http://myserverip/mongocharts/index.js

Any advice on this issue ?

My nginx configuration involves this part:

   location /mongocharts/ {
        proxy_pass http://0.0.0.0:1578/;
   }

I modified the connection port for development purpose.

Is there any environment variable that we can configure in docker-compose to specify the root path from where the application should serve content ?

Thanks,

François

[Tom Hollander]

Hi François -

Currently the links to those resources are hard-coded to live under the / directory .I'll look into whether we can make this customisable but for now it is not possible to change this. 

This is beyond my area of expertise, but you could probably configure nginx to rewrite these paths in the proxy.

Tom

[Quentin Honoré]

Hi,

I front the same issue.
Is the path still hard-coded ?

[Tom Hollander]

Hi Quentin and François -

Charts is built on Stitch, which now uses an address resolution service to determine the API endpoint. This allows for flexibility in choosing hosting regions for the cloud version of the service, although for on-prem use (as used by Charts) we always want to use the same location. So Charts implements this endpoint and attempts to return the right path, but it must be an absolute URL.

The address resolution service is accessed by Charts calling api/client/v2.0/app/mongodb-charts-xxxxx/location and this returns an absolute path which is used for all subsequent API calls. In the 0.12 release of Charts (just released) we now correctly handle non-standard ports and in cases where it sits behind a proxy that changes the hostname or protocol. (In 0.11 this scenario wasn't working). However if you want to access Charts from a virtual path, that isn't supported out of the box. If you can configure your proxy to rewrite the call to the /location service then it may be possible to get this working.

HTH

Tom

[Andrea Giancola]

Hi all.

I have the exact need addressed here:

In the 0.12 release of Charts (just released) we now correctly handle non-standard ports and in cases where it sits behind a proxy that changes the hostname or protocol.

Where can I find documentation for accomplishing this? (i.e. configuring the "hostname" returned by .../location endpoint, which is used to prosecute the flow after a successful login)?

Thank you

Andrea Giancola

[Tom Hollander]

Hi Andrea -

We haven't made this configurable - however we have a lot more logic in our implementation of the /location endpoint to try to ensure it returns the correct value. Are you saying you are still getting the wrong value in the 0.12 release? If so can you elaborate on your setup, what hostname is expected and what it is returning?

Tom

[Andrea Giancola]

We are running the mcharts server behind nginx as a reverse proxy. The hostname is provided by ddns,net.

nginx config:

server {

  listen 80;

  listen [::]:80;

  server_name <our public hostname>.ddns.net;

  location / {

      proxy_pass http://<our internal ip>:8180;

  }

}

Before the reverse proxy there is a port forwarding service, that map port 80 as public port 8080.

Putting everything together, we access MongoDB Charts through the url: 

http://<public hostname>.ddns.net:8080/login

and location endpoint response is:

{"deployment_model": "GLOBAL", "location": "US-VA",...., "hostname": "http://<internal ip>:8180"  }

which makes login timeout.

We were originally trying configuring HTTPS on reverse proxy, but we just get a more explicit warning on the browser about mixing http and https requests, which actually exposed the problem clear in the first place. 

Thanks.

[Tom Hollander]

My guess is that your proxy may not be sending the forwarded host properly to Charts. Can you check what headers it is sending?

Tom

[Andrea Giancola]

I have tried adding specific headers to nginx config, to no avail -- same behaviour by /location endpoint.

I've traced the outgoing HTTP requests  from nginx proxy towards internal MongoDB Charts installation:

(test a)

Hypertext Transfer Protocol

    GET /api/client/v2.0/app/mongodb-charts-gclnn/location HTTP/1.0\r\n

    X-Forwarded-Host: <my public hostname>.ddns.net:80\r\n

    X-Forwarded-Server: <my public hostname>.ddns.net\r\n

    X-Forwarded-For: <my client ip>\r\n

    Host: <internal ip>:8180\r\n

    Referer: http://<my public hostname>.ddns.net:8080/login\r\n

    ...

(test b)

Hypertext Transfer Protocol

    GET /api/client/v2.0/app/mongodb-charts-gclnn/location HTTP/1.0\r\n

    Forwarded: host=<my public hostname>.ddns.net\r\n

    Host: <internal ip>:8180\r\n

    Referer: http://<my public hostname>.ddns.net:8080/login\r\n

    ...

[Tom Hollander]

Thanks Andrea. This should be OK, so I'll need to look into whether we are handling all of these headers correctly. In the meantime are you able to try setting the Host header to your public hostname to see if that works?

Tom

[Andrea Giancola]

Thank you Tom!

Following your suggestions,  I finally managed to find a working configuration for my scenario. Here it is, complete with https:

server {

  listen 443 ssl;

  listen [::]:443 ssl;

  server_name <public hostname>.ddns.net;

  ssl_certificate <...>/fullchain.pem;

  ssl_certificate_key <...>/privkey.pem;

  include /etc/letsencrypt/options-ssl-nginx.conf;

  location / {

      proxy_pass http://<internal ip addr>:<internal port>;

      proxy_set_header Host $http_host;

      proxy_set_header X-Forwarded-Proto https;

  }

}

A couple of remarks:

 - we need to set X-Forwarded-Proto for https to work; still, other X-Forwarded-* settings seem to have no effect on returned location (unless I did something wrong), only setting Host works

 - since we have an external port remapping service in front of the reverse proxy, we need to set the outgoing Host header with the $http_host nginx variable, which returns the full incoming Host header content, and not for example $host:$server_port 

Thank you again for the prompt support! I'm sure this can help other people too.

[Tom Hollander]

Great to hear you got it working. Still thanks for the feedback - we're looking at supporting the X-Forwarded-Host header too as it seems that should ideally work as well. 

Tom