Jump to content

Error 401 in webclient after upgrade to Emby 3.0.5781.8


fc7
Go to solution Solved by fc7,

Recommended Posts

After updating to latest Emby stable version 3.0.5781.8, I can no longer login to the server while connecting from the Internet through an Apache SSL reverse-proxy, as I was before the update.

The login screen doesn't finish to load and any attempt to manually login will result in a "Invalid username or password error".

My setup is very specific so I would like to detail it in case it helps to narrow down the actual issue:

 

Webclient ==> Internet (SSL) ==> Apache Reverse-Proxy (SSL Termination) ==> LAN (no SSL) ==> Emby Server

 

On top of it I'm also authenticating clients using basic auth against the proxy. This means, that before anything gets to Emby, the proxy will request a username and password to the client.

Until last update this worked flawlessly. The client will connect, the proxy will request for a username and password and once provided the connection will go on as normal.

After yesterday's upgrade, this is not the case anymore.

The client will connect, the proxy will request for a username and password and once provided the connection will go on and parts of the web will load as normal but other parts, will fail with a 401 response from the proxy server (unauthorize request).

 

My default browser is Firefox (v43) but I also tried with a different browser, Midori, based on webkit. With Midori I'm able to connect and login as usual.

I'm a little bit lost. I don't know if the problem is the browser, the new version of Emby and the changes in the webclient or something else.

 

As I said before, this setup was working flawlessly until I upgraded Emby. :(

Edited by fc7
Link to comment
Share on other sites

This a screenshot of Firefox developer console (network tab) where you can see how the browser is loading many parts of the page while other requests fail with (401).

 

567846b81e786_Screenshotfrom201512211935

Link to comment
Share on other sites

I just checked with a network trace that all the GET (ie: GET /System/Info/Public) requests that the proxy is rejecting with a 401 error are being sent by the browser without the "Authorization" HTTP header.

Requests that are sent, with the Authorization HTTP header are getting a correct reply from the proxy.

 

Any ideas why some requests sent by the browser are missing the "Authorization" header and some others don't?

 

These is the list of some requests that are failing:

 

GET /System/Info/Public
GET /DisplayPreferences/home?client=webclient
GET /users/public
GET /Branding/Configuration

 

I can't see what they have in common.

 

BTW I tried with Safari and I can login fine but if for example I want to play some song, the browser will request again for credentials, when it shouldn't. An important difference is that Safari at least asks for credentials again, while Firefox will not and try again a couple of times before failing.

Link to comment
Share on other sites

Here is an example of a "BAD" request (note the missing Authorization header):

 

Client request:

GET /Branding/Configuration HTTP/1.1
Host: emby.fercasas.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0
Accept: application/json
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
x-emby-authorization: MediaBrowser Client="Emby Web Client", Device="Firefox 43.0", DeviceId="970085857d56e1b4ecd8a978ed434f15fb4cbeae", Version="3.0.5781.8"
Referer: http://emby.fercasas.com/web/login.html
origin: http://emby.fercasas.com
Connection: keep-alive

Server reply:

HTTP/1.1 401 Unauthorized
Date: Mon, 21 Dec 2015 20:30:31 GMT
Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips
WWW-Authenticate: Basic realm="Please provide your network credentials to continue"
Content-Length: 381
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>401 Unauthorized</title>
</head><body>
<h1>Unauthorized</h1>
<p>This server could not verify that you
are authorized to access the document
requested.  Either you supplied the wrong
credentials (e.g., bad password), or your
browser doesn't understand how to supply
the credentials required.</p>
</body></html>

And here of a "GOOD" one (note the presence of the Authorization header):

 

Client request:

GET /web/scripts/site.js?v=3.0.5781.8 HTTP/1.1
Host: emby.fercasas.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Referer: http://emby.fercasas.com/web/index.html
Authorization: Basic ZmNhc2FzOmVkZGllaHVudGVy
Connection: keep-alive

Server reply:

HTTP/1.1 200 OK
Date: Mon, 21 Dec 2015 20:30:25 GMT
Server: Mono-HTTPAPI/1.1
X-UA-Compatible: IE=Edge
X-Frame-Options: SAMEORIGIN
Vary: Accept-Encoding
X-Powered-By: ServiceStack/4.00 Unix/Mono
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization, Range, X-MediaBrowser-Token, X-Emby-Authorization
Content-Encoding: deflate
ETag: db9a9b6636ef8d67ca44059db9974680
Cache-Control: public, max-age=31536000
Expires: Tue, 20 Dec 2016 20:30:25 GMT
Content-Type: application/x-javascript
Content-Length: 14004
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Link to comment
Share on other sites

blankstar85

I'm getting the same thing, Only i'm running windows. I just upgraded today and the issues started.

 

Well it should be noted that my setup uses a linux Reverse proxy. I have the router throwing all port 80/443 to a virtualized linux box running nginx. It reverse proxies the request to the windows host which is running emby on the default ports.

 

Everything worked until i updated today.

Edited by blankstar85
Link to comment
Share on other sites

Did you try different browsers too?

In my case I tried with Mozilla 38 and 43, IE 11 and Safari.

Mozilla 43 and Safari had problems but IE 11 and Mozilla 38 worked. So it's a combination of things. Browser version plus changes done in Emby. As you said everything worked before the upgrade. :(

 

Sent from my iPhone using Tapatalk

Edited by fc7
Link to comment
Share on other sites

 

Here is an example of a "BAD" request (note the missing Authorization header):

 

Client request:

GET /Branding/Configuration HTTP/1.1
Host: emby.fercasas.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0
Accept: application/json
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
x-emby-authorization: MediaBrowser Client="Emby Web Client", Device="Firefox 43.0", DeviceId="970085857d56e1b4ecd8a978ed434f15fb4cbeae", Version="3.0.5781.8"
Referer: http://emby.fercasas.com/web/login.html
origin: http://emby.fercasas.com
Connection: keep-alive

Server reply:

HTTP/1.1 401 Unauthorized
Date: Mon, 21 Dec 2015 20:30:31 GMT
Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips
WWW-Authenticate: Basic realm="Please provide your network credentials to continue"
Content-Length: 381
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>401 Unauthorized</title>
</head><body>
<h1>Unauthorized</h1>
<p>This server could not verify that you
are authorized to access the document
requested.  Either you supplied the wrong
credentials (e.g., bad password), or your
browser doesn't understand how to supply
the credentials required.</p>
</body></html>

And here of a "GOOD" one (note the presence of the Authorization header):

 

Client request:

GET /web/scripts/site.js?v=3.0.5781.8 HTTP/1.1
Host: emby.fercasas.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Referer: http://emby.fercasas.com/web/index.html
Authorization: Basic ZmNhc2FzOmVkZGllaHVudGVy
Connection: keep-alive

Server reply:

HTTP/1.1 200 OK
Date: Mon, 21 Dec 2015 20:30:25 GMT
Server: Mono-HTTPAPI/1.1
X-UA-Compatible: IE=Edge
X-Frame-Options: SAMEORIGIN
Vary: Accept-Encoding
X-Powered-By: ServiceStack/4.00 Unix/Mono
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization, Range, X-MediaBrowser-Token, X-Emby-Authorization
Content-Encoding: deflate
ETag: db9a9b6636ef8d67ca44059db9974680
Cache-Control: public, max-age=31536000
Expires: Tue, 20 Dec 2016 20:30:25 GMT
Content-Type: application/x-javascript
Content-Length: 14004
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive

 

In case it helps, that doesn't look like an emby response. i would make sure there aren't any http request headers getting dropped by the proxy, which it sounds like might be happening.

Link to comment
Share on other sites

In case it helps, that doesn't look like an emby response. i would make sure there aren't any http request headers getting dropped by the proxy, which it sounds like might be happening.

Is there anything special that you miss or that you see that is wrong in the response.

I'm lost here and the only thing that changed is the Emby version. Too add more other people is reporting issues with nginx too. All of them after the last Emby upgrade.

 

If it makes sense to you I can rollback to the previous Emby stable version .5 and test. I'm running Emby on a VM and I took a snapshot before upgrading just in case. What do you think?

 

 

Sent from my iPhone using Tapatalk

Link to comment
Share on other sites

If you are talking about the "BAD" response. Of course it doesn't look like Emby. Because is not. It's just the proxy response to an unauthorized request. And is caused because the request is missing the "Authorization" header. Without it the proxy will just refuse to forward the request to the backend server. Emby in this case.

 

 

Sent from my iPhone using Tapatalk

Link to comment
Share on other sites

if i had to guess, i bet the proxy is dropping the custom x-emby-authorization header

 

In the bad request the x-emby-authorization header is right there, in the browser get request.

Problem is that this header is missing:

Authorization: Basic ZmNhc2FzOmVkZGllaHVudGVy

Hence why the proxy is returning a 401 error code. The proxy will not do anything with the "x-emby-authorization" it will pass it as is, it will just care about the Authorization (literally) header that is not coming in the browser request.

There are two separate authorization headers. One is called "x-emby-authorization" that Emby cares about and the other is called "Authorization" that the proxy cares about. The last one is not coming in some of the browser requests (I already provided some examples of requests that always fail, in case it helps) and that's why the proxy is rejecting it with a 401.

 

Can you think of any change in the webclient code that can make the browser to skip this header for some requests?

 

Action plan:

I will rollback Emby to .5, make a test and get a network trace at the same time. If after the rollback everything works, I will go and compare the network traces and each HTTP request to try to understand what changed between versions that causes this new behavior.

Let me be clear, I'm not chasing an Emby bug here, the code is probably just fine but the fact that it actually changed can cause that I just need to do some configuration change in the proxy to adapt to the new Emby version.

Link to comment
Share on other sites

well the browser sends the request with x-emby-authorization. my guess is that request header is missing by the time it reaches emby server.

Link to comment
Share on other sites

well the browser sends the request with x-emby-authorization. my guess is that request header is missing by the time it reaches emby server.

 

Sorry Luke, maybe I'm just not explaing myself correctly.

That request, the bad one, never, ever reaches Emby, it's rejected by the proxy itself because it's not an authorized request ("Authorization" header missing).

Forget the "x-emby-authorization" header for a moment since it has nothing to do in this scenario. Focus on the "Authorization" header.

 

The flow with the bad request will be like this:

 

1- The client send the GET request to the proxy without the Authorization header.

2- The proxy inspects the GET request sent by the client and it looks for the Authorization header. It's missing.

3- The proxy rejects the request and reply the client with a 401 error code. The client requests never reaches Emby.

 

In a good request scenario it will be like this:

 

1- The client send the GET request to the proxy including the Authorization header set.

2- The proxy inspects the GET request sent by the client and it looks for the Authorization header. It's present, then it checks that the user credentials (proxy user credentials, not emby user credentials they are separate) are valid. If they are, it will accept the request and pass it to the Emby server with all the headers (including both "x-emby-authorization" and "Authorization" headers as sent by the client).

3- Finally the client requests reaches Emby, Emby will process it (and probably look at the "x-emby-authorization" header among other things and reply back to the proxy which in turn will return it to the client.

 

As you can see the problem has nothing to do with "x-emby-authorization" but with "Authorization" header missing in the client request. :(

From the RFC (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html):

14.8 Authorization

      A user agent that wishes to authenticate itself with a server--
      usually, but not necessarily, after receiving a 401 response--does
      so by including an Authorization request-header field with the
      request.  The Authorization field value consists of credentials
      containing the authentication information of the user agent for
      the realm of the resource being requested.

          Authorization  = "Authorization" ":" credentials

      HTTP access authentication is described in "HTTP Authentication:
      Basic and Digest Access Authentication" [43]. If a request is
      authenticated and a realm specified, the same credentials SHOULD
      be valid for all other requests within this realm (assuming that
      the authentication scheme itself does not require otherwise, such
      as credentials that vary according to a challenge value or using
      synchronized clocks).

Did I explain myself better now? Let me know if there is something that is confusing or any other detail that you miss from my explanation.

Edited by fc7
Link to comment
Share on other sites

the change that was made was we switched from using the Authorization header to X-Emby-Authorization. Actually it was made for the purpose of reverse proxies because we were putting custom values in the Authorization header that was causing problems with other software. I don't recall what platform had a problem with it, I guess we'll have to search. But that's basically it, we were never using the Authorization header in a way that other software would understand so that's why it was changed.

Link to comment
Share on other sites

the change that was made was we switched from using the Authorization header to X-Emby-Authorization. Actually it was made for the purpose of reverse proxies because we were putting custom values in the Authorization header that was causing problems with other software. I don't recall what platform had a problem with it, I guess we'll have to search. But that's basically it, we were never using the Authorization header in a way that other software would understand so that's why it was changed.

 

I understand. What is really weird is that is not failing for all the requests as I showed above and it's not failing for every browser. It seems to me a combination of factor, not just the Emby code change regarding this header.

Firefox 38 works while 43 doesn't. IE 11 works.

Now that I think off, I saw this behavior before the update too, but only with Chrome while all the other browsers worked (even Firefox 43). I don't know which version because I never use Chrome but I remember it was loading parts of the webclient and constantly asking for user and password for others.

 

I'm not sure if my comments help but If there is any test or thing that you want me to verify or information I can provide, just let me know.

Link to comment
Share on other sites

@Luke: in Firefox console, only for the failing requests I see this message "Requesting url without automatic networking" does it tells you anything?

Link to comment
Share on other sites

I've noticed the same problem. I have an Apache reverse proxy which I connect to over SSL. This then forwards on to emby unencrypted. After the most recent update the login page doesn't finish loading any more and the web client doesn't work. I've tried on desktop and mobile Chrome. Did you ever get it working fc7?

Link to comment
Share on other sites

No. Still struggling. :(

For what it worth IE 11 and Firefox 38 works.

 

I will try to dig more during the weekend but as Luke confirmed they modified the way Emby uses http headers and it pretty much for sure that this change caused the current miss behavior behind the proxy. I will try to workaround it from the proxy configuration but I'm not sure if it will be possible.

If I find any solution rest assure that I will share it here.

 

 

Sent from my iPhone using Tapatalk

Edited by fc7
Link to comment
Share on other sites

what are the differences in requests between browsers?

 

As far as I could test Firefox v43 is missing the Authorization header and it's adding the Origin header. On the other hand Firefox <= v38 is missing the Origin header but it's adding the Authorization header.

Check the following screenshots:

 

F43 - Configuration request:

 

567eeeb00dca9_f43_Configuration_request.

 

F28 - Configuration request:

 

567eee7dc1d86_f28_Configuration_request.

 

F43 - public request:

 

567eef55640e3_f43_public_request.png

 

 

F28 - public request:

 

567eef64606d0_f28_public_request.png

 

Let me know if you need anything else.

Edited by fc7
Link to comment
Share on other sites

Is it possible that this problems are related to CORS and one of the requests that goes to an external server, to get the Christmas song?

 

From Firefox 43 console:

 

20:56:57.056 Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://github.com/MediaBrowser/Emby.Resources/raw/master/themes/holiday/christmas.wav. (Reason: CORS header 'Access-Control-Allow-Origin' does not match 'https://render.githubusercontent.com').1 <unknown>
 

I will keep investigating anyway...

Link to comment
Share on other sites

no, it'll handle that.

 

Ok. Any thoughts on why F43 will drop the Authorization header and add the Origin header instead for some specific requests and older versions doesn't?

Link to comment
Share on other sites

yea we've adopted browser fetch api's over the older XmlHttpRequest and firefox 38 doesn't support fetch so it's using the older methods.

 

what about configuring the proxy to ignore it?

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
×
×
  • Create New...