Auth/networking designed to isolate access to proxied connections

[snydergd]

Is your feature request related to a problem? Please describe.
I'm using FRP to expose plainapp behind transparernt authentication middleware (similar to Vouch/OAuth2-Proxy with nginx), which creates quite a nice access control for the app.

I'm having trouble finding a way to restrict access to PlainApp to just connections coming through my proxy.

PlainApp binding on localhost/127.0.0.1 would work just fine, and because of this, I don't want it binding on other addresses, since I don't have a need and makes some risk. People accessing PlainApp from my network in this case is unwanted. From what I can tell, the access controls also require user interaction and couldn't be bypassed in the proxy scenario with a header or anything like that (passwords are harder to steal if no one ever types them).

Describe the solution you'd like
To have localhost as an option in the list of addresses to bind (keeping others on the local network from accessing the app directly), even if other network addresses are available.

Or - allow or require the password to be passed in a header in setups like mine.

Describe alternatives you've considered
I thought about having the proxy layer authenticate so the user doesn't have to type the password, even exposing the login form to my local network is more than I really want to do.

[ismartcoding]

You can set a long password in the Password settings.

[snydergd]

@ismartcoding Thanks for the note. I noticed that, but even with the long password there are a couple challenges behind the proxy. Here is my explanation of those:

• User gets prompted to log in twice - once in my auth/sso layer, and once in the app itself
• Network clients can still access the login screens and interact with server logic. Historically these have had enough complexity/surface area that people have found exploits - e.g. wordpress, so it feels better if the logic unauthenticated users can interacted with was extremely limited, such as to just header validation logic that happens before any other app logic is loaded.
• LAN clients unnecessarily have the same access as my proxy. They are more likely malicious than clients on my phone, and I'm more likely in trouble already if there is something already on my phone. While not listening on LAN addresses still has some risk, it's a lot less in my mind than phone ones, and I might feel OK with just taking off the password if I knew that only they had access.

I hope that makes sense - happy to explain more. Thanks for taking a look.

[ismartcoding]

I believe you are requesting a whitelist feature, where only IP addresses listed in the whitelist would be granted access to the PlainApp webpage.

[snydergd]

@ismartcoding That would be one way to address it, and if I could tell it to bind on localhost/127.0.0.1 instead of the LAN or carrier IPs, it would essentially be a simple version of that on most devices.

However, having an option/switch to say "Require in auth header" for the password would be the overall better option if choosing one or the other.

Both tactics together would provide more benefit, but I would be happy with one or the other.