Reverse Proxy / URL

[dragon2611 29]

Was trying to see if I could get this working via a reverse proxy, turns out that yes it will work as long as the proxy is using the root path on the domain/subdomain for emby.

 

Interestingly the address option in the plugin will take subdirectory but it causes some strange behaviour, I was originally going to proxy /kodi/ then strip this prefix from the URL passed to the emby server (So the emby server would just see the normal url request)

 

If in the address i put

 

myserver.mydomain.com/media and set the port to 443 the request that the hits the proxy ends up getting is.

 

myserver.mydomain.com/media:443 where the URL actually contains the port number, so I suspect whilst the plugin accepts a server address with a / in this actually breaks something.

 

Ideally the plugin either needs validation to stop people entering a path after the server address or it needs to handle it properly

myserver.mydomain.com/kodi - as the server address causes

xxx.xxx.xxx.xxx - [29/Dec/2015:22:28:20 +0000] "GET /kodi:443/mediabrowser/Users/Public?format=json HTTP/1.1" 403 13


myserver.mydomain.com/kodi/ - as the server address causes

xxx.xxx.xxx.xxx - [29/Dec/2015:22:29:32 +0000] "GET /kodi/:443/mediabrowser/Users/Public?format=json HTTP/1.1" 403 13

Edited December 30, 2015 by dragon2611

[Angelblue05 4131]

All the paths used to access your server via the add-on are: {server}/emby/ 

 

Edit: In the beta version only, at the moment.

Edited December 30, 2015 by Angelblue05

[Middling 3]

I reported this a few weeks ago and Angelblue05 fixed it in version 1.1.63.

 

I tried a recent beta a couple of days ago and can confirm reverse proxying with nginx now works with the Kodi plugin.

 

Here's my nginx.conf:

	server {
		listen 443 ssl default_server;
		listen [::]:443 ssl default_server;
		ssl	on;
		server_name	files.example.org;
		ssl_certificate      /usr/local/etc/nginx/ssl/files.example.org.chained.crt;
		ssl_certificate_key  /usr/local/etc/nginx/ssl/files.example.org.key;
		ssl_trusted_certificate	/usr/local/etc/nginx/ssl/files.example.org.chained.full.crt;
		ssl_session_timeout  24h;
		ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;
		ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS;
		ssl_dhparam /usr/local/etc/nginx/ssl/dhparam.pem;
		ssl_prefer_server_ciphers   on;
		ssl_stapling on;
		ssl_stapling_verify on;
		resolver 8.8.8.8;
		ssl_session_cache shared:SSL:3m;
		access_log	/var/log/nginx/files.example.org.access.log;
		error_log	/var/log/nginx/files.example.org.error.log	crit;
		log_not_found	off;
		charset utf-8;
		location / {
			alias			/usr/local/www/files.example.org/;
			autoindex		off;
		}
		location /emby {
			proxy_set_header Upgrade $http_upgrade;
			proxy_set_header Connection "upgrade";
			proxy_http_version 1.1;
			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-By $server_addr:$server_port;
			proxy_pass http://emby.wired.lan.example.org:8096/emby;
			proxy_redirect off;
		}
	}

Note the absence of a trailing / in the location entry for emby.

 

All the Emby clients seem to use /emby?api_key instead of /emby/?api_key for the WebSocket.  Not a huge problem but something to keep in mind when configuring your reverse proxy.

 

It would probably be a good idea for the Emby server to make the WebSocket additionally available from a subdirectory of /emby (/emby/WebSocket/?api_key for example) and for clients to gradually move to this new path.  This would allow for a trailing / in the location directive for nginx configs and potentially provide a solution to the problems some people seem to be having with using Apache as a reverse proxy (as they could define /emby and /emby/WebSocket as separate locations).

[fc7 123]

You may want to try "/embywebsocket" to access the websocket. I proposed this change some time ago and it should be already in the code.

 

As stated in a previous post, many client apps still need to be updated tough.

Edited December 31, 2015 by fc7

[Middling 3]

You may want to try "/embywebsocket" to access the websocket. I proposed this change some time ago and it should be already in the code.

 

The current location already works fine when using nginx as the reverse proxy.

 

I don't think it's a good idea to have /embywebsocket in addition to /emby as it would require all reverse proxies to have separate entries for both paths and just isn't as tidy.

 

Better to have the web socket within a subdirectory of /emby, that way it will work for accessing the Emby server directly, using nginx as a reverse proxy (with /emby proxied), and Apache (with /emby and /emby/WebSocket proxied separately).