Proxy path whitelisting

[Re4mstr 5]

Greetings.

I come to you today because I am having issues connecting to my instance through the Android application.

My proxy is currently Pangolin, which offers authentication before being able to access the URL. As with many other mobile applications, the use of api's requires me to whitelist certain URL-paths, as they do not support authenticating in the proxy first.

This leads me to the following: What are the least amount of whitelistings needed, to be able to authenticate and use the app on mobile?

You can read the Pangolin documentation on other applications here having guides:
https://docs.fossorial.io/Pangolin/bypass-rules

 

Thank you in advance.

[Abobader 3464]

Hello Re4mstr,

** This is an auto reply **

Please wait for someone from staff support or our members to reply to you.

It's recommended to provide more info, as it explain in this thread:

Thank you.

Emby Team

[Luke 42078]

Hi, I would think /emby and everything underneath as well as /embywebsocket

[Re4mstr 5]

9 hours ago, Luke said:

Hi, I would think /emby and everything underneath as well as /embywebsocket

Hi,

Thanks for the answer, and I landed on this solution yesterday after some more testing.

The issue I have with this, is that in the browser, if I just append /emby to my base url, I bypass the auth.

I hoped there were a less "wildcard" approach.

[sh0rty 717]

On 6/5/2025 at 10:20 AM, Re4mstr said:

Hi,

Thanks for the answer, and I landed on this solution yesterday after some more testing.

The issue I have with this, is that in the browser, if I just append /emby to my base url, I bypass the auth.

I hoped there were a less "wildcard" approach.

Late to the Party. But at least these are the ones I needed to whitelist for having everything in the app functional and having Pangolin 2FA/Passkey login in the Web Browser. Perhaps Luke can elaborate if something is not necessary. 

Edited August 3, 2025 by sh0rty

[Luke 42078]

Yikes, that looks like it's going to be painful. I would just whitelist /emby/*

[sh0rty 717]

5 hours ago, Luke said:

Yikes, that looks like it's going to be painful. I would just whitelist /emby/*

 When whitelisting /emby/*, also the web login bypasses Pangolin Login page. But it could be easier mate :

 

Edited August 4, 2025 by sh0rty

[Re4mstr 5]

On 8/3/2025 at 10:20 PM, sh0rty said:

Late to the Party. But at least these are the ones I needed to whitelist for having everything in the app functional and having Pangolin 2FA/Passkey login in the Web Browser. Perhaps Luke can elaborate if something is not necessary. 

This is great, I am now only missing the top right "user menu" button (profile pic) from the app on mobile...

Thanks for this, though, guess I'll look through the API docs to figure out what more needs whitelisted to get the menu up.

[sh0rty 717]

1 hour ago, Re4mstr said:

This is great, I am now only missing the top right "user menu" button (profile pic) from the app on mobile...

Thanks for this, though, guess I'll look through the API docs to figure out what more needs whitelisted to get the menu up.

Meanwhile things changed on the server it seems. This is working for me now:

Edited January 4 by sh0rty

[Re4mstr 5]

Appreciate it, Sh0rty. Everything works as far as I can tell.

I'll make sure to submit this to the Pangolin Docs as soon as possible.

Marking this as solved for now.

[sh0rty 717]

3 hours ago, Re4mstr said:

Appreciate it, Sh0rty. Everything works as far as I can tell.

I'll make sure to submit this to the Pangolin Docs as soon as possible.

Marking this as solved for now.

This whole clingy opening paths thing would not be necessary if Emby apps would support custom proxy headers. But this dream will never come true I guess.

Feel free to give the proposal an upvote:

 

Edited January 4 by sh0rty

[dede1337 0]

any updates about this?

[sh0rty 717]

These are the current rulesets needed for path based auth bypass. Feel free leave a reaction in the linked thread two posts above, if you also feel the need of header auth to finally ditch the following path exclusions.

[Babatom 6]

@sh0rty

If it opens up so many paths, does it even make sense anymore?

[sh0rty 717]

9 hours ago, Babatom said:

@sh0rty

If it opens up so many paths, does it even make sense anymore?

Just for the feeling that the WebUI access is protected. An attacker would need to know that he need to use the Android App. But that's it. That's why I created the Feature Request for custom headers which would make the bypass rules obsolete.

[Babatom 6]

@sh0rtyI have only enabled these two paths and haven't noticed any restrictions so far

[darkassassin07 652]

The individual Emby apps are able to fully command and control Emby server. You need to whitelist all the paths required for this to make these apps function at all; which means all the paths needed to command and control your server are bypassing the additional authentication.

An attacker looking to directly command your server would then be bypassing this superfluous authentication, while legitimate users just trying to reach the login page are stuck with additional steps...

 

This does nothing to add actual security, while increasing friction for users. Security theatre at best.

 

[Babatom 6]

@darkassassin07The Emby login still appears, only the Pangolin login is bypassed. And only admins can control the server. I understand this isn't ideal, but what other options are there if you want to expose publicly?

[darkassassin07 652]

That's my point, the Pangolin login is easily bypassed by anyone actually looking to attack; so it adds no actual useful security and serves only as an additional barrier to genuine users trying to login. I'm not sure where you get the idea it's even necessary.

I've quite happily had my server exposed publicly for 10 years... There's no need to put additional login pages in front of it; and doing so, particularly with this method, adds no real value/security.

In my setup there is a reverse proxy handling wrapping traffic in ssl, and only responding to a very specific subdomain while dropping other traffic (direct IP connections for example); that's plenty sufficient.