MagicMirror behind a NGinx Reverse Proxy

[sdetweil]

@ember1205 said in MagicMirror behind a NGinx Reverse Proxy:

but that is not defined on the nginx host.

but it is as a server entry in the nginx.conf

I have just set one up and see the same…

but the proxy doesn’t explicitly ask to pass the uri too

[sdetweil]

@ember1205 so, if u take off the mmirror part of the 1st server and use the / location to proxy pass it works, so you are correct… it passed the uri portion along too…

[ember1205]

When using a proxy server like this, it functions mostly like a content switch. In other words, you can redirect specific paths to different back-end hosts - this is commonly done when you have different servers holding different kinds of content.

When you have a VIP acting as a Content Switch, anything not explicitly defined for a particular path will be handled by the default VIP. In this case, he has not actually defined the /mmirror path, so appending that to his domain will result in the DEFAULT server getting the traffic as opposed to the mirror. That’s why the 404.

I believe that the directive I mentioned earlier is all that needs to be defined in order to get the nginx proxy handling that path accordingly…

[fbr1969]

Re: MagicMirror behind a NGinx Reverse Proxy

I watched my Nginx error file and found :

2019/12/24 10:20:45 [error] 2341#2341: *1 open() "/var/www/html/socket.io/socket.io.js" failed (2: No such file or directory), client: XX.XXX.XX.XXX, server: mydomain.com, request: "GET /socket.io/socket.io.js HTTP/1.1", host: "mydomain.com", referrer: "https://mydomain.com/mmirror/"```

So, I tried to modify my nginx config file.
Here’s the final configuration, working fine (don’t forget to change ‘mydomain.com’), and your private IP adress.
Magic Mirror will be avaiable by : https://mydomain.com/mmirror :

server {
    listen      80;
    server_name mydomain.com;
    return      301 https://$server_name$request_uri;
}

server {

    # Setup HTTPS certificates
    listen       443 default ssl;
    server_name  mydomain.com;
    ssl_certificate /etc/letsencrypt/live/mydomain.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/mydomain.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

    # Access to Magic Mirror
    location /mmirror/ {
        proxy_pass              http://192.168.10.60:8080/;
        #proxy_redirect          http://192.168.10.60:8080 /mmirror;
        #proxy_set_header Host $http_host;
        #proxy_set_header X-Real-IP $remote_addr;
        #proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        #proxy_set_header X-Forwarded-Proto $scheme;
        proxy_pass_request_headers on;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host $http_host;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $http_connection;
        # Disable buffering when the nginx proxy gets very resource heavy upon streaming
        proxy_buffering off;
    }

        location /socket.io {
                # Proxy Magi Mirror Websockets traffic
                proxy_pass http://192.168.10.60:8080;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_set_header X-Forwarded-Protocol $scheme;
                proxy_set_header X-Forwarded-Host $http_host;
        }

    location / {
        root   /var/www/html;
        index  index.html ;
    }
}

[ember1205]

@fbr1969

A couple of questions about your configuration…

• It seems that you configured ONLY for access to the mirror with a /mmirror path as well - is this accurate? I can’t tell where the ‘default’ VIP might be pointing to.

• It appears that you have to handle the /socket.io path independently of the of /mmirror path, and that leads me to wonder if there is javascript code being returned to the browser that ALSO needs to be rewritten inline?

[fbr1969]

@ember1205

Hi,
With my shortcut “mmirror”, I can access directly to the default Magic Mirror page (define in my MM config.js file), at home (LAN) or at work (by Internet).
And effectively, I had needed to handle the /socket.io path independently of the of /mmirror path to correct the error I found I my NGinx error log. And that worked like that.
I’ sorry, but I don’t know how it works exactly…

[ember1205]

@fbr1969 said in MagicMirror behind a NGinx Reverse Proxy:

@ember1205

Hi,
With my shortcut “mmirror”, I can access directly to the default Magic Mirror page (define in my MM config.js file), at home (LAN) or at work (by Internet).
And effectively, I had needed to handle the /socket.io path independently of the of /mmirror path to correct the error I found I my NGinx error log. And that worked like that.
I’ sorry, but I don’t know how it works exactly…

Thanks for the extra detail - your description increases my suspicion/concern that there is likely a lot of JS content being delivered directly to the browser that is not being otherwise rewritten, hence the need for the additional path for socket.io

On my mirror, with a total of five modules (all default except one), there are twenty-six JS scripts that are delivered to the browser for “local” execution. Fortunately, of them, ONLY the socket.io call has a hard path to the root of the server:

< script type="text/javascript" src="/socket.io/socket.io.js"></script>

Nothing else uses the leading “/” in the path which means they are all relative paths and will properly pass through a reverse proxy for access. Even though the other twenty-five scripts can be downloaded, there’s nothing to say that the content WITHIN them can execute if they make any subsequent calls using hard-coded information that isn’t being rewritten.

Reverse proxy servers are awesome tools, but the configuration has to be ‘perfect’ to ensure everything will work properly now and in the future. And rewriting JS is not always trivial.