Migrating to Buster (Raspberry 4) breaks Nginx Proxy

In my case i am running mopidy-party as guest-mode and mopidy-mobile as DJ-mode.
Access to mopidy-party with lan IP only (without port number).
Access to mopidy-mobile is restricted with login.
I realized this with nginx in conjunction with iptables and that worked over the last 2 years without
any troubles.

My config:

server {
listen 80 default_server;
server_name _;

    location /mobile {
	proxy_pass http://localhost:6680;
	proxy_http_version 1.1;
	proxy_set_header Upgrade $http_upgrade;
	proxy_set_header Connection "upgrade";
	auth_basic "Restricted";
	auth_basic_user_file /etc/nginx/.htpasswd;				
			}
			
    location / {
            proxy_buffering off;
            proxy_pass http://localhost:6680;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
            rewrite /mopidy/(.*) /mopidy/$1 break;
            rewrite /(.*) /party/$1 break;
            proxy_redirect off;
			}

}

iptables drops port 6680.

works with below environment:
debian stretch
nginx: 1.10.3
mopidy 2.2.3
mopidy-spotify; 3.1.0
mopidy-party: 0.3.1
mopidy-mobile: 1.9.0

The issue now is, that the clients are loading the right pages, ask for credentials but at this stage
booth extension (party, mobile) are hanging (trying to connect without success).

Nginx error.log:

2020/05/20 17:57:25 [error] 799#799: *44 connect() failed (111: Connection refused) while connecting to upstream, client: 10.0.0.11, server: _, request: “GET /mopidy/ws HTTP/1.1”, upstream: “http://[::1]:6680/mopidy/ws”, host: “10.0.0.41”
root@rpi4:~# cat /var/log/nginx/error.log
2020/05/20 17:57:25 [error] 799#799: *44 connect() failed (111: Connection refused) while connecting to upstream, client: 10.0.0.11, server: _, request: “GET /mopidy/ws HTTP/1.1”, upstream: “http://[::1]:6680/mopidy/ws”, host: “10.0.0.41”
2020/05/20 17:57:44 [error] 800#800: *41 connect() failed (111: Connection refused) while connecting to upstream, client: 10.0.0.11, server: _, request: “GET /vendors/fontawesome-all.min.css HTTP/1.1”, upstream: “http://[::1]:6680/party/vendors/fontawesome-all.min.css”, host: “10.0.0.41”, referrer: “http://10.0.0.41/
2020/05/20 17:57:45 [error] 799#799: *39 connect() failed (111: Connection refused) while connecting to upstream, client: 10.0.0.11, server: _, request: “GET /favicon.ico HTTP/1.1”, upstream: “http://[::1]:6680/party/favicon.ico”, host: “10.0.0.41”

mopidy.log:

2020-05-20 18:11:02,509 INFO [843:HttpServer] tornado.access: 304 GET /party/ (127.0.0.1) 3.12ms
2020-05-20 18:11:02,559 INFO [843:HttpServer] tornado.access: 200 GET /party/vendors/fontawesome-all.min.css (127.0.0.1) 4.37ms
2020-05-20 18:11:02,565 INFO [843:HttpServer] tornado.access: 200 GET /party/style.css (127.0.0.1) 3.07ms
2020-05-20 18:11:02,572 INFO [843:HttpServer] tornado.access: 200 GET /party/vendors/mopidy.min.js (127.0.0.1) 4.03ms
2020-05-20 18:11:02,583 INFO [843:HttpServer] tornado.access: 200 GET /party/controller.js (127.0.0.1) 3.27ms
2020-05-20 18:11:02,595 INFO [843:HttpServer] tornado.access: 200 GET /party/vendors/bootstrap.min.css (127.0.0.1) 46.59ms
2020-05-20 18:11:02,596 INFO [843:HttpServer] tornado.access: 200 GET /party/vendors/angular.min.js (127.0.0.1) 21.63ms
2020-05-20 18:11:02,649 WARNING [843:HttpServer] tornado.access: 404 GET /party/favicon.ico (127.0.0.1) 1.09ms
2020-05-20 18:11:10,546 INFO [843:HttpServer] tornado.access: 200 GET /mobile/index.html (127.0.0.1) 2.69ms
2020-05-20 18:11:10,594 INFO [843:HttpServer] tornado.access: 200 GET /mobile/css/ionic-light.min.css?v=1.9.1 (127.0.0.1) 7.34ms
2020-05-20 18:11:10,707 INFO [843:HttpServer] tornado.access: 200 GET /mobile/images/icon-192x192.png?v=1.9.1 (127.0.0.1) 2.87ms
2020-05-20 18:11:32,487 WARNING [843:HttpServer] mopidy.http.handlers: HTTP request denied for Origin “http://10.0.0.41
2020-05-20 18:11:32,488 WARNING [843:HttpServer] tornado.access: 403 GET /mopidy/ws (127.0.0.1) 2.71ms
2020-05-20 18:12:32,497 WARNING [843:HttpServer] mopidy.http.handlers: HTTP request denied for Origin “http://10.0.0.41
2020-05-20 18:12:32,499 WARNING [843:HttpServer] tornado.access: 403 GET /mopidy/ws (127.0.0.1) 2.71ms

The changelogs of mopidy said, that the version of torpedo have changed from 4.x to 5.x.
Could this be the reason?
Is it possible that mopidy has it’s own redirect/forward function which interferes with nginx?
The question for me now is, where and how should i start examining the problem?

Many Thanks in Advance.

I think for nginx proxying this is the wrong forum :wink:

If you suspect upgraded tornado might break things, why not install an older version of mopidy and test it?

Could these warnings could be the problem? https://docs.mopidy.com/en/latest/ext/http/#confval-http-allowed_origins

@bluepuma77
@kingosticks
thx

In the meanwile i found a slolution to run stretch on buster and my system is up and running.
Thx to Botspot!
https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=251757&p=1664490#p1664490
The problem now ist to pipe/forward the guest’s audio output to the host’s audio jack with pulseaudio.

AUDIO IS ALSO WORKING SINCE YESTERDAY!!!
Now you can run Mopidy with Spotify on Stretch over Buster with a Raspberry 4 and VDESKTOP.

THX TO BOTSPOT!

It’s great you found a way to get this working, if this is what you want.

But please, anyone else landing here: use the latest version of Mopidy (and it’s extensions) and if you have this particular use-case you need to correctly set Mopidy’s HTTP Frontend allowed_origins config setting.

please do me a favour:

  1. read the docs

allowed_origins= ‘A list of domains…’

I am running a jukebox with mopidy/spotify and mopidy-party on a public place

with 10-20 clients connected. how can I know their ‘domains’?

  1. read my post

  2. read the discussions about the problems with pyspotify on raspberry 4 with buster

Greatings from good old EUROPE

For the case of a proxy server you need to understand what’s going on:

  • Clients are making requests to your nginx proxy server at 10.0.0.41:80
  • Mopidy is serving content from localhost:6680
  • Clients sending requests to the proxy and they set the two headers we care about as:
    • Host: http://10.0.0.41 (the port is omitted because it’s the default HTTP port)
    • Origin: http://10.0.0.41
  • Nginx takes those client requests and uses them to make new requests to Mopidy. In doing so it alters the Host header, changing it to $proxy_host.
  • Mopidy receives the requests with headers set as:
    • Host: http://localhost:6680
    • Origin: http://10.0.0.41

This is now a same-origin problem. It’s not exactly the same as what the docs are trying to describe but when you follow through what a nginx does then it’s the same outcome. And you’d fix it the same way by configuring allowed_origins.

[http]
allowed_origins = 10.0.0.41

Or, maybe you prefer to make nginx set Host differently. I’m not sure if I like this solution as much:

proxy_set_header Host $host;

However, if for some reason neither of these solutions worked and you were happy with the security implications (which I assume you are if you’ve decided to use the old software as work-around), you could’ve alternatively set Mopidy’s http/csrf_protection = false. That is also documented on the same page (my emphasis):

Disabling this will remove the requirement to set a Content-Type: application/json header for JSON-RPC POST requests. It will also disable all same-origin checks, effectively ignoring the http/allowed_origins config since requests from any origin will be allowed.

Lastly,

  1. read the discussions about the problems with pyspotify on raspberry 4 with buster

I don’t understand what you mean by this. Can you be more specific?

THANK YOU VERY MUCH!!!
YOU WERE ABSOLUTELY RIGHT!!!

My system is running perfect!

Greatings from Vienna

PS: If you plan to come in our Town, pls let me know it (for having a
couple of drinks).