Jump to content

Odd GET requests


darkassassin07
 Share

Go to solution Solved by pir8radio,

Recommended Posts

darkassassin07

When I am accessing my server through my reverse proxy with the android app I am receiving these requests approx every 10-15min

<client IP here> [11/Jul/2018:21:05:48 -0700] "mydomain.com" "GET /embywebsocket?api_key=&deviceId= HTTP/1.1" 404 127
<client IP here> [11/Jul/2018:21:22:17 -0700] "mydomain.com" "GET /emby:443/emby/system/info/public HTTP/1.1" 404 127
My WAN address as listed in the dashboard of my server is:

Https://mydomain.com/emby:443

 

Nothing has stopped functioning, I'm just curious as to why the app is adding /emby:443 to the beginning of /emby/system/....

And not adding /emby to the websocket request.

 

 

 

/edit

<client IP here> [11/Jul/2018:21:22:17 -0700] "mudomain.co." "GET /emby/system/info/public HTTP/1.1" 200 198
It looks like this request is being resent with the correct address once the initial request fails.

The websocket one is not being re-requested with the correct address at all.

Edited by darkassassin07
Link to comment
Share on other sites

Not sure but if you customized the wan address make sure that it is only the address and does not include any subfolders.

Link to comment
Share on other sites

darkassassin07

Emby is at the location /emby behind my reverse proxy. Thats why there is a subdirectory.

 

Https://Mydomain.pw/emby/ proxies to http://<localip>/:8096

 

 

I have added a / to the very end to make https://mydimain.com/emby/:443 in the dashboard. Not sure if that will help or even matter but it couldn't hurt.

 

This is still functioning just fine, all the rest of the requests are made to mydomain.com/emby/ as they should be its just these two that arent making it where they should

 

 

/edit

 

The added / didnt help, now '/emby/:443' is prepended to the request instead of '/emby:443'

Edited by darkassassin07
Link to comment
Share on other sites

darkassassin07

Im curious, what is the 'embywebsocket' request supposed to do? Its not at least somewhat important that it gets a 404 and is not re-requested with the proper uri?

Link to comment
Share on other sites

darkassassin07

I knew that much just from the name lol,

I meant more what is that actually used for. I should have been more clear I guess.

 

I could just add a location in nginx for that uri to redirect manually, but that seems like a workaround to a bug rather than an actual fix.

Edited by darkassassin07
Link to comment
Share on other sites

It allows the server to send data to the apps in response to various events and actions that my have occurred.

Link to comment
Share on other sites

I knew that much just from the name lol,

I meant more what is that actually used for. I should have been more clear I guess.

 

I could just add a location in nginx for that uri to redirect manually, but that seems like a workaround to a bug rather than an actual fix.

 

You shouldn't have to do anything special for websocket connections if your emby config, you probably have your timeout set to short and your ws connections are force disconnecting and being reopened until nginx forces them closed again.   are you stripping off the /emby before it gets to your emby server?  What does your config look like?    

 

Nginx config example:  https://emby.media/community/index.php?/topic/48236-setting-up-emby-behind-a-reverse-proxy-nginx/?p=457670

 

Websocket timer settings:  https://emby.media/community/index.php?/topic/48236-setting-up-emby-behind-a-reverse-proxy-nginx/?p=569575

Link to comment
Share on other sites

darkassassin07

I'll look at it a little closer and post my nginx config when I get home.

 

Looking at my logs the only 'websocket' requests at all are exactly the same as the one posted above. The android app itself fails to prepend /emby/ to the request so it returns a 404

The app never attempts the correct uri.

 

The /emby:443/emby/system/info request is re-requested with the correct uri everytime it gets the 404 as above

Edited by darkassassin07
Link to comment
Share on other sites

I'll look at it a little closer and post my nginx config when I get home.

 

Looking at my logs the only 'websocket' requests at all are exactly the same as the one posted above. The android app itself fails to prepend /emby/ to the request so it returns a 404

The app never attempts the correct uri.

 

The /emby:443/emby/system/info request is re-requested with the correct uri everytime it gets the 404 as above

 

oh i see what you are saying..   the logs are probably not entirely true, what do you have as your WAN address in emby?   do you show the /emby there? if so remove it so it is just your domain.com

Link to comment
Share on other sites

darkassassin07

If I do that emby apps will be making requests to https://mydomain.com/ and every single one will 404

It has to have the /emby/ or it wont make it to https://mydomain.com/emby/ as it should. As I have said it is only the websocket request that is being directed to the wrong place. Everything else is sent to https://mydomain.com/emby/<request here> exactly as it should be.

 

I mean, I can try it once im home, but I really dont think that will do anything other than result in 404 for everything so noone using the apps can connect at all. Web app only.

Edited by darkassassin07
Link to comment
Share on other sites

If I do that emby will be making requests to https://mydomain.com/ and every single one will 404

It has to have the /emby/ or it wont make it to https://mydomain.com/emby/ as it should. As I have said it is only the websocket request that is being directed to the wrong place. Everything else is sent to https://mydomain.com/emby/<request here> exactly as it should be.

 

I mean, I can try it once im home, but I really dont think that will do anything other than result in 404 for everything so noone can connect at all.

 

Lets check out your config first once you get home.  I would depend more on your nginx logs if you keep them.  look for the same entry, the emby logs are a little wonky when using a reverse proxy..   or pm me your domain name and i can probably see if its the app or the server. 

Link to comment
Share on other sites

darkassassin07

I probably should have mentioned those are the nginx logs.

 

 

Here is my NGINX config:

Definitely looking for some input on it, curious how I have done given this is pretty new to me.

 

Port 443 of mydomain.com is forwarded directly to this server.

In emby:

'public https port number' = 443

'external domain' = mydomain.com/emby/

The remote access address on the dashboard is https://mydomain.com/emby/:443 (how can I make this not a link?)

user www-data;
worker_processes 4;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
	worker_connections 1024;
}

http {
	sendfile on;
	tcp_nopush on;
	tcp_nodelay on;
	types_hash_max_size 2048;
	server_tokens off;
	
	include /etc/nginx/mime.types;
	default_type application/octet-stream;


	log_format  simple  '$remote_addr [$time_local] "$host" "$request" $status $body_bytes_sent';
	log_format  verbose  '$remote_addr [$remote_user][$time_local] "$host" "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$http_x_forwarded_for"';

	error_log /<path>/error.log;
	access_log /<path>/main.access.log simple;


# pretty heavy on the security mainly as a learning experience. Not something I have played with before this. 
	ssl on;
	ssl_protocols TLSv1.2;
	ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA";
	ssl_dhparam <file path>;
	ssl_prefer_server_ciphers on;
	ssl_session_cache shared:SSL:10m;
	ssl_buffer_size 32k;
	ssl_certificate <file path>;
	ssl_certificate_key <file path>;
	add_header X-Xss-Protection "1; mode=block" always;
	add_header X-Content-Type-Options "nosniff" always;
	proxy_hide_header X-Powered-By;
	add_header 'Referrer-Policy' 'no-referrer';
	add_header Strict-Transport-Security "max-age=31536000" always;
	add_header Content-Security-Policy "frame-ancestors <host names>; default-src 'self'; script-src 'self'; img-src 'self'; style-src 'self'; font-src 'self'; object-src 'self'";
	add_header Public-Key-Pins <redacted>;

	gzip on;
	gzip_disable "msie6";
	gzip_comp_level 6;
	gzip_min_length 1100;
	gzip_buffers 16 8k;
	gzip_proxied any;
	gzip_types text/plain text/css text/js text/xml text/javascript application/javascript application/x-javascript application/json application/xml application/rss+xml image/svg+xml;


	server_names_hash_bucket_size 128;
	map_hash_bucket_size 64;


	client_body_timeout   10;
	client_header_timeout 10;
	keepalive_timeout     30;
	send_timeout          10;
	proxy_read_timeout 90;
	keepalive_requests    10;


	proxy_set_header HOST $host;
	proxy_set_header X-Real-IP $remote_addr;
	proxy_set_header Range $http_range;
	proxy_set_header If-Range $http_if_range;
	proxy_set_header X-Forwarded-Proto $scheme;
	proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
	proxy_http_version 1.1;


	server {
		server_name <mydomain.com>;
		listen 443 ssl default_server;
		listen [::]:443 ssl default_server;

		satisfy any;
		allow 192.168.0.0/24;
		auth_basic "Restricted";
		auth_basic_user_file <file path>;
		deny all;


			#----------------- Error Handling ---------------------
		proxy_intercept_errors on;

#I can't get this to work, with it uncommented anything that is not on the ip whitelist (ie the local network) gets a 401 without being asked to enter a password at all. 
#If I disable the ip whitelist and have basic_auth only it works just fine.... 

#		error_page 401 /401.html; #401 = not authorized (not logged in)
#		location = /401.html {
#			allow all;
#			auth_basic off;
#			alias /usr/share/nginx/html/401.html;
#			access_log /<path>/unauth.access.log simple;
#			internal;
#		}

		error_page 404 /404.html; #404 = not found
		location = /404.html {
			auth_basic off;
			allow all;
			alias /usr/share/nginx/html/404.html;
			access_log /<path>/unrouted.access.log simple;
			internal;
		}

		error_page 500 502 503 504  /50x.html;  #50X = server error
		location = /50x.html {
			auth_basic off;
			allow all;
			alias /usr/share/nginx/html/50x.html;
			access_log /<path>/httperror.log simple;
			internal;
		}



			#----------------  Misc  ----------------------------
		location = /Robots.txt {alias /etc/nginx/robots.txt;}
		location = /robots.txt {alias /etc/nginx/robots.txt;}    #not sure if this is necessary for an https server

		location / {   #unrouted/unknown request logging
			return 404;
			access_log /<path>/unrouted.access.log;
		}

			#---------------  Emby  --------------------
		location = / {return 301 https://$host/emby/;} #a re-direct for now. This will become something later. 
		location /Items/ {return 301 https://$host/emby$uri?$args;}   #these two are for the statistics plugin to load media images. 
		location /web/ {return 301 https://$host/emby$uri?$args;}

		location /emby/ {
			auth_basic off;
			allow all;
			access_log /<path>/emby.access.log simple;
			client_max_body_size 20M;
			proxy_pass http://192.168.0.106:8096/;
			proxy_set_header Range $http_range;
			proxy_set_header If-Range $http_if_range;
			proxy_set_header Upgrade $http_upgrade;
			proxy_set_header Connection "upgrade";
		}
	}



# irrelevant locations have been removed. 
} 
Here are the odd requests from the NGINX unrouted.access.log:

[12/Jul/2018:22:31:32 -0700] "mydomain.com" "GET /embywebsocket?api_key=9ebc2f2e2eb946d19766a30f90636aaf&deviceId=d7afb2777c850f74 HTTP/1.1" 404 127 
[12/Jul/2018:22:52:15 -0700] "mydomain.com" "GET /emby/:443/emby/system/info/public HTTP/1.1" 404 127
The search term 'socket' does not exist in the emby.access.log

The /info request does show up in that log

correctly as '/emby/system/info/public' just after the 404 with /emby/:443

Link to comment
Share on other sites

darkassassin07

I could add:

location /embywebsocket {
    Return 301 https://$host/emby/embywebsocket?$args;
}
To manually redirect it,

But thats a work around to what I think may be a bug. It would be better to fix the root cause

 

(double post because editing a long post with code in it always screws me over)

I also noticed I forgot to 'allow all; auth_basic off' for robots.txt while proof reading

Edited by darkassassin07
Link to comment
Share on other sites

I probably should have mentioned those are the nginx logs.

 

 

Here is my NGINX config:

Definitely looking for some input on it, curious how I have done given this is pretty new to me.

 

Port 443 of mydomain.com is forwarded directly to this server.

In emby:

'public https port number' = 443

'external domain' = mydomain.com/emby/

The remote access address on the dashboard is https://mydomain.com/emby/:443 (how can I make this not a link?)


Here are the odd requests from the NGINX unrouted.access.log:

[12/Jul/2018:22:31:32 -0700] "mydomain.com" "GET /embywebsocket?api_key=9ebc2f2e2eb946d19766a30f90636aaf&deviceId=d7afb2777c850f74 HTTP/1.1" 404 127 
[12/Jul/2018:22:52:15 -0700] "mydomain.com" "GET /emby/:443/emby/system/info/public HTTP/1.1" 404 127
The search term 'socket' does not exist in the emby.access.log

The /info request does show up in that log

correctly as '/emby/system/info/public' just after the 404 with /emby/:443

 

 

 

I would strip the /emby off of the requests going to emby...   then start your "basic auth...." after the rewrite.  This doesnt mean dont use domain.com/emby  the rewrite will just strip that off the requests going to the emby server, making your RP more transparent and act as if there is no reverse proxy.   I dont think the 301 redirect would work for you anyway.  some of the android os's dont allow 301's within apps. 

        location /emby/ {                                  #note the backslash after emby
                rewrite ^/emby(/.*)$ $1 break;             #this will strip /emby from the requests going into emby backend
Edited by pir8radio
Link to comment
Share on other sites

darkassassin07

Would you mind breaking down and explaining that rewrite command?

I haven't messed with those yet, im not really sure how they work.

 

However I don't believe that will change anything, every request that goes through the 'location /emby/' works exactly as it should already.

 

The two requests that we are talking about are going through 'location /' where it is just logged to a different file and given a 404.

 

If 301 wont work I could make a copy of the /emby/ location and change it to /embywebsocket. Then its just a proxy like the other one.

 

 

I shouldn't have to though. The app should be requesting that correctly (adding /emby/) like it does for every other request, but it isnt.

 

 

location / {   #unrouted/unknown request logging
			return 404;
			access_log /<path>/unrouted.access.log;
		}

Here are the odd requests from the NGINX unrouted.access.log

Edited by darkassassin07
Link to comment
Share on other sites

darkassassin07

I did give it a try:

Added that, reloaded nginx, opened a web browser and connected to emby through nginx and I was given this screen:

 

Nothing actually functions on this page and I had been automatically signed in the last time I connected before this

This was an issue related to my contend security policy, not emby/nginx locations.

 

 

adding the rewrite command didnt change anything.

Edited by darkassassin07
Link to comment
Share on other sites

I think you are making things more difficult than they need to be..   /emby/  is only used on a handful of items in the emby server. ( i think branding, items, users, maybe a few others) by you using it in your path for nginx without stripping it off in the rewrite you are causing the emby items that actually need /emby to come up as /emby/emby/ and breaking your links.    you can try my server I'll PM you my info..   See if that makes you feel more warm and fuzzy to send me yours..  I cant troubleshoot much more, its not an emby issue.   its an nginx issue.   The /emby strip should fix you up.   look out for my PM.  

Link to comment
Share on other sites

so to be clear, the strip code should be in and your wan address in emby server should NOT have /emby on it. 

Link to comment
Share on other sites

darkassassin07

The /emby/ is already being stripped off the uri by the location itself.

When nginx receives the request '/emby/emby/system/...'

It passes '/emby/system/... ' to the emby server.

 

I will send you my domain though.

Link to comment
Share on other sites

The /emby/ is already being stripped off the uri by the location itself.

When nginx receives the request '/emby/emby/system/...'

It passes '/emby/system/... ' to the emby server.

 

I will send you my domain though.

 

That's what I'm saying   /emby/system is not a normal emby url.    /system is though..     for example your home page probably looks like: https://domain.com/emby/web/index.html#!/home.html           but the actual emby url is:  https://domain.com/web/index.html#!/home.html       /emby was added to cover old reverse proxy configs.  

 

So,  you PM'ed me your url, and i noticed you send your base to /emby anyway...    why even use /emby   you don't need it?    your redirects are whats screwing with android.        If you MUST use domain.com/emby then we need to clean up your config a little..   But i would recommend you go with subdomains. 

Link to comment
Share on other sites

darkassassin07

Im using sub domains to differ between the devices im connecting to, and locations to access the services through that particular device.

 

I dont want to have several domains mainly because I'm using manual dns verification for my certs and Its a pain to have to deal with.

 

 

location = / {return 301 https://$host/emby/;} #a re-direct for now. This will become something later.

Edited by darkassassin07
Link to comment
Share on other sites

Im using sub domains to differ between the devices im connecting to, and locations to access the services through that particular device.

 

I dont want to have several domains mainly because I'm using manual dns verification for my certs and Its a pain to have to deal with.

 

 

 

That makes sense...  wildcard certs are available but usually cost more.     I also noticed all of the 301's in your config, you might find android sometimes does not obey those,  I think its mostly from http to https though.  

Link to comment
Share on other sites

darkassassin07

The vast majority of the requests to nginx are something like this:

/emby/Sessions/Playing/Progress

/emby/Audio/

/emby/Users/

Etc...

 

They all have the /emby/stripped and

 

/Sessions/Playing/progress

Etc... Is passed to the emby server

 

The /emby/emby/system path I searched for in the log, those above are just the bottom few lines of that log.

 

 

@@pir8radio

Do you have any idea why my 401 page wont work with auth_basic off and allow all?

If I disable the ip whitelist it works just fine. Everyone is asked to auth and are given the 401 page if the fail/decline.

 

If I leave the whitelist on and disable auth_basic (server wide) external ips get the 401 page and the internal ones arent asked to auth as you would expect.

If both ip whitelist and auth_basic are enabled external ips are given a 401 without being asked to auth, and internal ones connect as normal.

 

 

 

 

/edit

Btw the 301s are for the statistics plugin to load images correctly through the web app. I didnt bother bring that up because the statistics plugin will become a separate server eventually.

 

Excluding the 301 for '/', that's temporary until I setup a different server that will be located there.

 

Nothing within the android app is routed through those at all.

 

 

 

I have added a location to proxy '/embywebsocket' to emby manually and that is working. I knew I could do that from the beginning, I already had for the statistics plugin, but I was trying to get the devs to look into the app not sending that request the same way it does every other request.

 

I appreciate your help @@pir8radio :)

Edited by darkassassin07
Link to comment
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...