Jump to content

Error 401 in webclient after upgrade to Emby 3.0.5781.8


fc7
Go to solution Solved by fc7,

Recommended Posts

the absence of Authorization

 

I was just looking into doing that for specific requests (the ones that comes with a specific ORIGIN header). Doing it for all of them, means disabling proxy authentication and I don't really want to do that.

Also I want to understand what's is actually going on and the implications of changing the proxy configuration, if any.

 

If in the end the only option is to disable proxy authentication, I prefer to rollback Emby to the previous stable version and stay there until any better option arise. :(

Link to comment
Share on other sites

Ok. I just rolledback to the previous version 3.0.5781.5 and everything works fine with the same proxy setup and using Firefox 43. Thank God I'm using a VM and it was as simple as switching the virtual hdd.

 

I have now two virtual hdds one with Emby 3.0.5781.8 and another one with 3.0.5781.5 to continue with the troubleshooting.

 

@Luke: if you come up with any idea (knowing all the code changes made between versions in the webclient) on what can I test, I will go back to 3.0.5781.8 and test it. No problem. Just let me know.

Link to comment
Share on other sites

@Luke: the works "cross-domain", "cors" keep coming up. Forgive me if what I'm about to say is totally non-sense but is it possible that for some reason the browser thinks that he needs to a cross-domain request and hence why it's dropping the Authorization header and adding the Origin header for the requests that fails? I compare the requests done using the previous stable Emby version and the browser is not using the Origin header at all when its requesting "users/public" and "Branding/Configuration". I just wish I have more developing skills and knowledge to figure this out.

 

For example:

 

Request with credentials
By default, for non same origin request, browsers will not send credentials (such as HTTP Cookies, HTTP Authentication and client-side SSL certificates). A specific attribute has to be set on the XMLHttpRequest object when it is invoked.

 

Edited by fc7
Link to comment
Share on other sites

More information. Firefox 38 is the last version that works with the latest stable Emby release (.8) with this reverse-proxy setup. Anything afterwards will fail.

Edited by fc7
Link to comment
Share on other sites

try the dev branch

 

It works!!! :)

What was the problem?

Any chance that the fix will go into stable soon?

Edited by fc7
Link to comment
Share on other sites

Did your test include this commit?

 

https://github.com/MediaBrowser/Emby/commit/e8bc3ce5987e46d6bc8370fac6f1e53ff6cfadb4

 

And if so, what version of mono? and if not, can you grab that and retry? thanks.

 

Yes. I waited for OBS to build the dev package for that commit.

Mono version 4.0.3.

Edited by fc7
Link to comment
Share on other sites

  • 1 month later...
gstuartj

@@fc7 I'm curious, what benefits are there to using HTTP basic auth? Hiding the login form/public parts of Emby from random visitors? With your setup do users still have to login a second time using the login web form, or are you passing those basic auth params to Emby somehow? Does basic auth work with all clients, e.g. Roku?

 

I'm happy with my setup, but if HTTP basic auth can work fairly seamlessly I'm interested.

Edited by gstuartj
Link to comment
Share on other sites

@@fc7 I'm curious, what benefits are there to using HTTP basic auth? Hiding the login form/public parts of Emby from random visitors? With your setup do users still have to login a second time using the login web form, or are you passing those basic auth params to Emby somehow? Does basic auth work with all clients, e.g. Roku?

 

I'm happy with my setup, but if HTTP basic auth can work fairly seamlessly I'm interested.

 

In my case the benefit is that I add an extra security layer since unauthorized visitors don't get to Emby at all. If there is any security flaw in mono or Emby that can be exploited this will also reduce the attack surface since someone would need first to get authorized by the proxy and only then they get to Emby. Also this added authentication layer is integrated with Active Directory, which makes user access a lot more easy to control.

To give you a broader picture, I have a few public sites published to the Internet. With this setup I can grant different users access to different sites, based on their Active Directory group membership which is pretty handy for me.

Yes, the users need to login twice, first against the proxy and then against Emby using the regular Emby login form.

Regading Emby client apps, I don't think they will work, but my users only use the webclient.

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...