dragon2611 27 Posted December 30, 2015 Share Posted December 30, 2015 (edited) 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 Link to comment Share on other sites More sharing options...
Angelblue05 4130 Posted December 30, 2015 Share Posted December 30, 2015 (edited) 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 Link to comment Share on other sites More sharing options...
Middling 3 Posted December 30, 2015 Share Posted December 30, 2015 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). 1 Link to comment Share on other sites More sharing options...
fc7 123 Posted December 31, 2015 Share Posted December 31, 2015 (edited) 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 Link to comment Share on other sites More sharing options...
Middling 3 Posted December 31, 2015 Share Posted December 31, 2015 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). Link to comment Share on other sites More sharing options...
Recommended Posts