darkassassin07 423 Posted July 26, 2018 Author Share Posted July 26, 2018 (edited) With the most recent update, the app no longer allows you to put a path in the host field while adding a server (example: https://mydomain.com/mymedia/). App version 3.0.2 The first request the android app makes to the host its been given is "GET /emby HTTP/1.1". While I happened to be using the location "/emby" to direct traffic through my reverse proxy, if I wanted to change that to something like "/mymedia" this is no longer possible. @@Luke The use of /emby threw you I think, so I'll try to be more clear using /mymedia as my proxy location: (this was my setup before the recent change just with /mymedia edited in instead of /emby) The app host field is (well was) set to "https://mydomain.com/mymedia"with the correct port. The emby external address shown in the dashboard is "https://mydomain.com/mymedia:443" When the app tries to connect it sends the request "GET /mymedia/emby HTTP/1.1" to mydomain.com. This request is received by the reverse proxy where it is matched to the location /mymedia. The proxy strips /mymedia from the URI passing the request "GET /emby HTTP/1.1" to the emby server. Because of this change this kind of setup is no longer possible. Your emby server can only ever reside at the root of your reverse proxy (ie: '/') or the location '/emby'. The app now sends the request "GET /emby HTTP/1.1" which in this example gets a 404 from the proxy without being passed to the emby server. Then it tries "GET /emby/system/info/public HTTP/1.1" which also receives a 404. This can no-longer be changed. The only issues I was having with the previous setup was having the request "GET /mymedia/:443/emby/system/info/public HTTP/1.1" sent to my proxy every few minutes filling my logs with garbage, and the websocket request being sent to "/embywebsocket" instead of "/mymedia/embywebsocket" like every other request the app made. Edited July 26, 2018 by darkassassin07 Link to comment Share on other sites More sharing options...
Luke 37045 Posted July 26, 2018 Share Posted July 26, 2018 We've never officially supported custom subpaths. The apps are always going to auto-add /emby. Link to comment Share on other sites More sharing options...
darkassassin07 423 Posted July 26, 2018 Author Share Posted July 26, 2018 I guess this has turned into a feature request then. Now that support has been added to have emby behind a proxy, this would make sense would it not? Emby is one of a few things I host, eventually I plan to have an index/landing page at the root of mydomain.com where a user can then link to any one of the services. The apps however will still need to be able to directly connect to emby through the /mymedia path. I just happened to be using /emby for that path. Link to comment Share on other sites More sharing options...
Luke 37045 Posted July 27, 2018 Share Posted July 27, 2018 Well we've managed to get this far without it. The problem is then we have to put a field for that on our connection screens, and users already think the connection process is complicated enough. Link to comment Share on other sites More sharing options...
darkassassin07 423 Posted July 27, 2018 Author Share Posted July 27, 2018 (edited) ... No you wouldn't...? Just allow the user to put the full host path just as I was. Ie host: 'https://mydomain.com/mymedia' Port: '1234' You haven't needed it for most people so far, but you only recently added the option to have emby behind a proxy. Edited July 27, 2018 by darkassassin07 Link to comment Share on other sites More sharing options...
pir8radio 1292 Posted July 27, 2018 Share Posted July 27, 2018 ... No you wouldn't...? Just allow the user to put the full host path just as I was. Ie host: 'https://mydomain.com/mymedia' Port: '1234' You haven't needed it for most people so far, but you only recently added the option to have emby behind a proxy. Well, I think the officially supported reverse proxy configuration is using sub-domains not sub-directories. All apps support the sub-domain method of a reverse proxy. I would say sub directories are unsupported considering like 95% of the reverse proxy connection issues on this forum are related to sub directories and the proxy not being transparent to the application server. Just my two cents though.. Link to comment Share on other sites More sharing options...
darkassassin07 423 Posted July 27, 2018 Author Share Posted July 27, 2018 I would say sub directories are unsupported considering like 95% of the reverse proxy connection issues on this forum are related to sub directories and the proxy not being transparent to the application server. Do you mean 'issues related to sub directories' as in people are trying to do something similar and its not working? Ofc it isn't, the app doesn't currently prepend the uri the user had given it to the requests its making. It really shouldn't be hard to take the uri entered into the host field and add it to any request the apps make to that particular server. Turning 'GET /embywebsocket?<args>' into 'GET /mymedia/embywebsocket?<args>' This would allow myself and other users to put the server in a subdirectory of a domain without adding any extra fields or complication to the average user. I don't see a downside? One of the problems with using a sub domain for me is that ddwrt provides local domain names for devices with a static dhcp lease. This only allows me to configure a single name per device and setting this to the same domain name allows me and my family to connect with the same domain name no matter where we are. If emby was the only thing I host that wouldn't be a problem, but I have several services that are all under that same name. Then as I have mentioned, the hassle of dealing with multiple domain names when it comes to re-creating my certs with manual dns verification every 3mo (LE)... I would also have to stick to several (sub) domains for every service because telling my users 'ok this one you add emby to the beginning like emby.mydomain.com and these three you have to put it after like mydomain.com/serviceA'. I get bothered enough by those that forget the 'https://' (port 80 is blocked by isp) Link to comment Share on other sites More sharing options...
pir8radio 1292 Posted July 27, 2018 Share Posted July 27, 2018 Do you mean 'issues related to sub directories' as in people are trying to do something similar and its not working? Ofc it isn't, the app doesn't currently prepend the uri the user had given it to the requests its making. It really shouldn't be hard to take the uri entered into the host field and add it to any request the apps make to that particular server. Turning 'GET /embywebsocket?<args>' into 'GET /mymedia/embywebsocket?<args>' This would allow myself and other users to put the server in a subdirectory of a domain without adding any extra fields or complication to the average user. I don't see a downside? One of the problems with using a sub domain for me is that ddwrt provides local domain names for devices with a static dhcp lease. This only allows me to configure a single name per device and setting this to the same domain name allows me and my family to connect with the same domain name no matter where we are. If emby was the only thing I host that wouldn't be a problem, but I have several services that are all under that same name. Then as I have mentioned, the hassle of dealing with multiple domain names when it comes to re-creating my certs with manual dns verification every 3mo (LE)... I would also have to stick to several (sub) domains for every service because telling my users 'ok this one you add emby to the beginning like emby.mydomain.com and these three you have to put it after like mydomain.com/serviceA'. I get bothered enough by those that forget the 'https://' (port 80 is blocked by isp) I run about 10 subdomains myself. I would make all of your services subdomains and just get a wildcard cert. The ddwrt names wouldn't be affected by using different subdomains on the wan side. Nginx handles the direction of subdomains through headers. Link to comment Share on other sites More sharing options...
darkassassin07 423 Posted July 28, 2018 Author Share Posted July 28, 2018 (edited) -edit- ill look into that in a bit, last I had read I couldn't use a wildcard in dns verification Edited July 28, 2018 by darkassassin07 Link to comment Share on other sites More sharing options...
pir8radio 1292 Posted July 28, 2018 Share Posted July 28, 2018 -edit- ill look into that in a bit, last I had read I couldn't use a wildcard in dns verification I guess im not sure what you mean by "dns verification"? Link to comment Share on other sites More sharing options...
darkassassin07 423 Posted July 28, 2018 Author Share Posted July 28, 2018 (edited) Proving you own/control said domain name via dns txt records while getting a cert. Im probably mixing up my terminology a bit... Edited July 28, 2018 by darkassassin07 Link to comment Share on other sites More sharing options...
Solution pir8radio 1292 Posted July 28, 2018 Solution Share Posted July 28, 2018 Proving you own/control said domain name via dns txt records while getting a cert. Im probably mixing up my terminology a bit... gotcha... yea, you can still verify with a wildcard. you just do it on your base domain name.. domain.com 1 Link to comment Share on other sites More sharing options...
darkassassin07 423 Posted July 29, 2018 Author Share Posted July 29, 2018 I ended up getting the wildcard cert then setting up subdomains on lan and wan. Thanks @@pir8radio 1 Link to comment Share on other sites More sharing options...
pir8radio 1292 Posted July 29, 2018 Share Posted July 29, 2018 I ended up getting the wildcard cert then setting up subdomains on lan and wan. Thanks @@pir8radio i'm just glad its working for you... sub domains really takes the headaches out of a reverse proxy.. Link to comment Share on other sites More sharing options...
darkassassin07 423 Posted August 15, 2018 Author Share Posted August 15, 2018 (edited) While it isn't really a major issue, With the current beta branch of emby for android the app is still making the request: [14/Aug/2018:22:48:17 -0600] "mydomain.com" "GET /emby/:443/emby/system/info/public HTTP/1.1" 404 564 (this is from my nginx access log) The odd part is the host name listed in the dashboard of the server as well as what was manually entered into the app is emby.mydomain.com. Everything sent to emby.mydomain.com is proxied/proxyed? to the emby server while mydomain.com is a dead end currently. This request is resent correctly as emby.mydomain.com/emby/system/info/public shortly after so it isn't actually breaking anything, it's just odd. Edited August 15, 2018 by darkassassin07 Link to comment Share on other sites More sharing options...
Luke 37045 Posted August 15, 2018 Share Posted August 15, 2018 Thanks for the info. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now