RandomNinjaAtk / docker-lidarr-extended

lidarr-extended :: Lidarr application packaged with multiple scripts to provide additional functionality
GNU General Public License v3.0
275 stars 24 forks source link

[Bug]: Unable to set up reverse proxy NGINX #101

Closed nrgbistro closed 1 year ago

nrgbistro commented 1 year ago

Describe the bug I'm able to access the web ui locally, but when I use NGINX and navigate to https://lidarr.domain.com, I get this error in the console:

Uncaught TypeError: Cannot read properties of null (reading 'Level') at Xv (index.js?h=qW5Re6lh9V2q10NfXZHJ1g:1:120437) at 69781 (index.js?h=qW5Re6lh9V2q10NfXZHJ1g:1:121063) at r (index.js?h=qW5Re6lh9V2q10NfXZHJ1g:1:1204234) at index.js?h=qW5Re6lh9V2q10NfXZHJ1g:1:1206145 at r.O (index.js?h=qW5Re6lh9V2q10NfXZHJ1g:1:1204626) at index.js?h=qW5Re6lh9V2q10NfXZHJ1g:1:1206161 at index.js?h=qW5Re6lh9V2q10NfXZHJ1g:1:1206166

To Reproduce Steps to reproduce the behavior:

  1. Set up application
  2. Go to local ip to ensure web ui is working
  3. Set up reverse proxy and see that you cannot access the web ui

Expected behavior Easy access to the web ui

Log Data From browser console:

GET https://lidarr.domain.me/api/v1/localization 401 send @ vendors.js?h=2eyxhEeUy7rSPiNslmqbbQ:1 ajax @ vendors.js?h=2eyxhEeUy7rSPiNslmqbbQ:1 jr @ index.js?h=qW5Re6lh9V2q10NfXZHJ1g:1 69781 @ index.js?h=qW5Re6lh9V2q10NfXZHJ1g:1 r @ index.js?h=qW5Re6lh9V2q10NfXZHJ1g:1 (anonymous) @ index.js?h=qW5Re6lh9V2q10NfXZHJ1g:1 r.O @ index.js?h=qW5Re6lh9V2q10NfXZHJ1g:1 (anonymous) @ index.js?h=qW5Re6lh9V2q10NfXZHJ1g:1 (anonymous) @ index.js?h=qW5Re6lh9V2q10NfXZHJ1g:1 index.js?h=qW5Re6lh9V2q10NfXZHJ1g:1

Uncaught TypeError: Cannot read properties of null (reading 'Level') at Xv (index.js?h=qW5Re6lh9V2q10NfXZHJ1g:1:120437) at 69781 (index.js?h=qW5Re6lh9V2q10NfXZHJ1g:1:121063) at r (index.js?h=qW5Re6lh9V2q10NfXZHJ1g:1:1204234) at index.js?h=qW5Re6lh9V2q10NfXZHJ1g:1:1206145 at r.O (index.js?h=qW5Re6lh9V2q10NfXZHJ1g:1:1204626) at index.js?h=qW5Re6lh9V2q10NfXZHJ1g:1:1206161 at index.js?h=qW5Re6lh9V2q10NfXZHJ1g:1:1206166

Docker Info:

Additional Context: I'm using the exact same Nginx Proxy Manager settings that I did for my normal Lidarr installation, which worked perfectly.

RandomNinjaAtk commented 1 year ago

This would be likely caused by a user miss configuration somewhere in the stack and is out of scope for support here.

I use this with the linuxserver.io SWAG reverse proxy using a subdomain without issue. Feel free to post on the discussions and maybe another user can assist. Support here is limited to extended script issues.

nrgbistro commented 1 year ago

As I said, my reverse proxy works with the linuxserver.io Lidarr docker image. Why would configuration change for this lidarr-extended image?

RandomNinjaAtk commented 1 year ago

You must of configured something differently.

maxpfandl commented 1 year ago

As I said, my reverse proxy works with the linuxserver.io Lidarr docker image. Why would configuration change for this lidarr-extended image?

Working fine for me with the linuxserver.io image and the extended version with nginx as reverse proxy. But since I see 401 errors: how do you authenticate?

nrgbistro commented 1 year ago

Initially I did not have authentication. I just turned it on and was able to access the form login page from lidarr.domain.com. Once I clicked login, I get the same error message as before and a blank screen. I don't see how this could be an issue with my configuration and not a bug with lidarr-extended.

maxpfandl commented 1 year ago

Initially I did not have authentication. I just turned it on and was able to access the form login page from lidarr.domain.com. Once I clicked login, I get the same error message as before and a blank screen. I don't see how this could be an issue with my configuration and not a bug with lidarr-extended.

Well, try basic auth: I assume the login page does some redirects which are not proxied correctly. But @RandomNinjaAtk is right: this has nothing to do with the extended script: this is only lidarr.

RandomNinjaAtk commented 1 year ago

Or could be miss configuration of the reverse proxy.

I use Lidarr's login form without issue via SWAG reverse proxy. I also use the provided template in SWAG for lidarr reverse proxy without any modifications other than setting the IP. Either way its not an issue with the scripts. Its a more general user config issue.

nrgbistro commented 1 year ago

Here is the current configuration of my nginx proxy manager: http://screenshot.how/aTTe8d. Does anything look wrong or do I need additional configuration data in the advanced tab?

EDIT: I've also tried basic auth and get the same issue.

maxpfandl commented 1 year ago

Well, I don't know what you're using to configure nginx here, but my config looks something like this below. I use basic auth on reverse proxy level, not at lidarr and make the calendarfeed public to import to google calendar.

map $http_upgrade $connection_upgrade {
    default Upgrade;
    ''      close;
}

server {
        client_max_body_size 30M;
        server_name lidarr.myserver.com;
        proxy_read_timeout 96000;
        proxy_send_timeout 96000;
        location / {
            auth_basic "AdminOnly";
            auth_basic_user_file /etc/nginx/sites-enabled/.pwlidarr;

            proxy_pass http://my.internal.ip.adress:8686;
            proxy_http_version 1.1;
            proxy_set_header   Upgrade $http_upgrade;
            proxy_set_header   Connection $connection_upgrade;
            proxy_set_header   Host $host;
            proxy_cache_bypass $http_upgrade;
            proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header   X-Forwarded-Proto $scheme;

        }
        location ^~ /feed/v1/calendar/ {
            auth_basic off;
            proxy_pass http://my.internal.ip.adress:8686;
            proxy_http_version 1.1;
            proxy_set_header   Upgrade $http_upgrade;
            proxy_set_header   Connection $connection_upgrade;
            proxy_set_header   Host $host;
            proxy_cache_bypass $http_upgrade;
            proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header   X-Forwarded-Proto $scheme;
        }

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/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
}
RandomNinjaAtk commented 1 year ago

The default SWAG lidarr subdomain config: https://github.com/linuxserver/reverse-proxy-confs/blob/master/lidarr.subdomain.conf.sample

Your problem is likely caused by not proxying the API, after reviewing the SWAG template config.