Redirecting unknown logins to Forbidden / Unauthorized page

I am wondering if there is any way to resolve this, because I think plex’s design here is a bit flawed.

I have a publicly accessible plex instance, via reverse proxy on my local network. If a user were to try to access my plex instance via, for example, plex.mydomain.com, they are first prompted to login (expected). But then if they login with an unauthorized account, they are still served plex content (just not content from my server). This seems like a flawed design, they should be accessing this content via plex.tv, not plex.mydomain.com.

Is it possible for the user to either be redirected to a Forbidden / Unauthorized page, or just plainly redirected to plex.tv so that I am not serving content to this rogue user?

Thanks

Be careful please…

If you’re running your proxy and you’re not cutting off all access on login failure,
is that Plex’s design problem or an implementation issue on your part ?

Plex does offer free streaming services with a FREE plex accounts.

That said, I think you need to look at how you implement your proxy for your domain.

My implementation is as follows;

  1. I have a locked-down DDNS for all those who I allow to connect to my domain.
  2. If I cannot resolve the ingress IP to a FQDN which I have allowed then my machine drops the packets and is a complete “hole in the internet”

I don’t think you’ve offered a solution though. If someone connects to your server by its FQDN, and reaches the login screen (which must be possible if you want to share your Plex instance this way), then they are able to attempt to login.

How are you determining a “failed” login at this stage? If I login to your server with my Gmail account, I am still served data from your server, just not media content from your server.

I have quite a lot of security built into my firewall and reverse proxy system, probably substantially more than most. But I don’t see how it’s possible to prevent this behavior.

And if there is a way, that’s what I’m asking. How?

I think you’re missing the point.

If your security is correct, they shouldn’t be able to login with plex credentials through your proxy without proper proxy credentials from you ???

Am I misunderstanding?

To my thinking: They hit your proxy first. If they can’t get through it, NOTHING about Plex should be accessible.

Without your proxy, they are still subject to plex.tv login requirements.
The most they will see is what Plex offers anyone . Nothing is from your server.

Blockquote
I think you’re missing the point.

I don’t think so…

Blockquote
If your security is correct, they shouldn’t be able to login with plex credentials through your proxy without proper proxy credentials from you ???

Again though, how can I prevent this? Plex credentials are nothing more than a google account. As I said, they will not be able to login and gain access to my content, but they are still being served data via my server. I am basically asking what that data consists of. Is it a single static webpage? To me it just looks like they should be redirected to plex.tv instead of being served that anything at all via my server.

And I’ll cover this in a moment, but I cannot provide “credentials” for my reverse proxy, as this would prevent plex from working.

Blockquote
Am I misunderstanding?
To my thinking: They hit your proxy first. If they can’t get through it, NOTHING about Plex should be accessible.

The problem is if I want to expose my server for remote access, they must be able to get through my reverse proxy. I would love to be able to add my identity provider / sso system as a forward auth in front of plex, but this would cause plex apps to not work. If there is a way for this to work, I’d love to know.

Blockquote
Without your proxy, they are still subject to plex.tv login requirements.
The most they will see is what Plex offers anyone . Nothing is from your server.

This is basically what I am saying and observing. I understand my server isn’t streaming plex’s ad supported content, but it seems weird I am serving access to it from my server rather than just redirecting to plex.tv or a 404.

How is this so?

The ONLY thing which happens is they loaded the Plex/web browser client (bundle) from your machine. This is the same you get from https://app.plex.tv

Yes, but, necessarily, it is my server that is serving the content which should normally originate from plex.tv. I find this to be strange behavior. Of course they must be served the login, but if they are not authenticated as a member of my plex account it should just redirect entirely to plex.tv so plex servers can handle this user.

And again I understand my server isn’t proxying the plex video content or anything, but it just seems like an unnecessary attack surface when I would rather it return a 404, and I don’t know the extent of what data I am serving. Like I said, is it a single static page? I don’t know.

Yes, This is different.

  1. Initially, when you loaded from a server, you were bound to that server (left panel menu of libraries to choose from)

  2. As things grew, they needed a way to switch from server to server without logging in multiple tabs/windows. At this point, “Plex/Web” and the clients all became Floating/Detached (at start) from the server IP they loaded from.

  3. Plex then added Plex-sourced content into that left panel.

  4. This is how my implementation locks down. I don’t allow any requests from anyone unknown to me.

But how is this achievable? You can whitelist IPs but this is not a good solution as almost everyone has dynamic IPs, and your IP changes on mobile connections, or when on a WiFi network outside your home. It would be easier and safer to use a VPN or Tailscale than managing it this way.

If you gave me your FQDN to reach your plex server for instance, how is your reverse proxy preventing me from reaching your login page? If there is a good solution to this other than whitelisting IPs, I am happy to learn.

  1. I whitelist DDNS FQDNs.
  2. If I’m going to allow someone access to my server on mobile, I give them WireGuard access as a client. (I use pfSense)

Right, that just isn’t a great solution for most people in my opinion. I have users that are old, tech ignorant people and I can’t possibly expect them to deal with VPNs or tailscale. And while DDNS would work for their home networks, it’s some additional services that I’d have to expect them to manage and it won’t work outside of their homes. Also 99% of plex users aren’t even using a reverse proxy where they can do this and this same behavior exists for them too.

I think it just makes so much more sense for the login to just redirect to plex.tv and eliminate this concern.

Then perhaps you have them all login via https://app.plex.tv (in a browser)
or via their normal account in an app.

They will automatically see what you’ve made available to them.

No proxy or vpn required (it’s all https and brokered by Plex)

This doesn’t solve the issue though. Again I am not concerned about my actual users accessing my instance. I don’t even provide it to them. Plex internally manages brokering connections to my server via Custom Server Access URL. But it wouldn’t matter if I did, because they are authorized users and are free to access my server.

I’m talking about rogue actors. Potential attackers that are scanning open ports and performing service discovery. If they are somehow able to find my plex instance (which isn’t difficult, I get dozens of attempted connections daily that I am aware of), then they can attempt to login and are served what should be served by plex.tv.

Again, I don’t think its a BIG risk, but if there is some vulnerability in that portion of plex, my server would needlessly be exposed to it.

Rogue actors — EXACTLY why I take steps myself. There is no single best solution for everyone.

I use FQDN whitelisting . I know others use MAC address whitelisting. If you want to lock it down to your satisfaction, there are a lot of choices.

Okay so then there is no way within plex to prevent this behavior then. That was essentially my question.

But saying this basically acknowledges that this impacts anyone using Plex’s built in Remote Access, since there would be no way to do IP or MAC filtering that way.

And IP and MAC filtering are more trouble than a VPN in my opinion, while being less secure. I wish plex would support OAuth/OIDC or something so I can manage this myself.

And there’s the fundamental problem… We all want different things / have different opinions.

My firewall supports dynamic FQDN resolution many others do not. I’ve had to implement it in my firewall instead of Plex but no matter, the end result is the same.

Sure, and thats fine. If I felt my users would be able to deal with VPN access I’d certainly do that. I have done I think as much as possible to secure my instance outside of whitelisting IPs which unfortunately is not a solution for my requirements.

But again, I am an exception in any event. I have significantly more security than 99% of users who are just port forwarding to their plex instance, and this behavior exists for them too, but without the tools I have in place to minimize access of rogue actors.

So it seems that all I’d really like to know are: 1) what is the extent of this concern? What specifically is my server exposing when a rogue user logs in with a random unauthorized account? and 2) Why can’t this just be eliminated by redirecting to plex.tv? Plex auth service already redirects to plex.tv to handle login, it just directs it back to my server even on a failed login for some reason.

That’s where you are wrong.
All they get is the Plex web app loaded into their browser. A few megabytes worth at most.
All what happens from then onwards, has nothing to do with your server. The web app communicates directly with media sources.
Which means if they are watching one of the free videos from plex.tv, it has nothing to do with your server. There will be no data traffic whatsoever between the user’s browser and your server while they’re watching.

The Plex web app is not a “website”.
A personal Plex server is not a"webserver".

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.