[GH-ISSUE #5151] Control of access parameters for multiple http type proxies from server side

gitea-mirror commented

2026-05-05 14:33:26 -06:00

Owner

Copy link

Originally created by @kzkaram on GitHub (Feb 2, 2026).
Original GitHub issue: https://github.com/fatedier/frp/issues/5151

Describe the feature request

When using FRP to enable multiple independent http type proxies various parameters such as the custom domain name and the bandwidth are set at the client side. Also native frp doesn't seem to provide a method for tying the authentication of a connection to a particular user to be controlled at the server side. I have installed and used fp-multiuser plugin to handle the latter. This allows a token file to be held at the server side and for a client side token to need to match a server side token in order to pass authentication. This is useful because it is one way in which a particular user can be allowed or disallowed to access the service. However it would be better if some method could exist which provides a way of defining a particular clients access parameters from some native frps configuration at the server side. For example something like a file (or the frps.toml itself) containing sets of parameters for each client, such as designated custom domain name, password(secret), bandwidth etc. On the client side the first two must then match those on the server in order to gain access, such that users can only use custom domain names provided by a central database to avoid possible duplications and that is also gated by a password so reduce possibility of someone else getting any kind of response based on a guessed domain name. Maybe this all doable right now but I just haven't understood how?

Describe alternatives you've considered

No response

Affected area

Docs
Installation
Performance and Scalability
Security
User Experience
Test and Release
Developer Infrastructure
Client Plugin
Server Plugin
Extensions
Others

Originally created by @kzkaram on GitHub (Feb 2, 2026). Original GitHub issue: https://github.com/fatedier/frp/issues/5151 ### Describe the feature request When using FRP to enable multiple independent http type proxies various parameters such as the custom domain name and the bandwidth are set at the client side. Also native frp doesn't seem to provide a method for tying the authentication of a connection to a particular user to be controlled at the server side. I have installed and used fp-multiuser plugin to handle the latter. This allows a token file to be held at the server side and for a client side token to need to match a server side token in order to pass authentication. This is useful because it is one way in which a particular user can be allowed or disallowed to access the service. However it would be better if some method could exist which provides a way of defining a particular clients access parameters from some native frps configuration at the server side. For example something like a file (or the frps.toml itself) containing sets of parameters for each client, such as designated custom domain name, password(secret), bandwidth etc. On the client side the first two must then match those on the server in order to gain access, such that users can only use custom domain names provided by a central database to avoid possible duplications and that is also gated by a password so reduce possibility of someone else getting any kind of response based on a guessed domain name. Maybe this all doable right now but I just haven't understood how? ### Describe alternatives you've considered _No response_ ### Affected area - [ ] Docs - [ ] Installation - [ ] Performance and Scalability - [ ] Security - [ ] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [ ] Server Plugin - [ ] Extensions - [x] Others

gitea-mirror

2026-05-05 14:33:26 -06:00

closed this issue
added the
lifecycle/stale
label

gitea-mirror commented

2026-05-05 14:33:29 -06:00

Author

Owner

Copy link

@fatedier commented on GitHub (Feb 3, 2026):

One practical way to solve this today is to build a server-side plugin (similar to fp-multiuser) that keeps a central “user/proxy policy” store and enforces it on frps (e.g., allowed custom domains, bandwidth limits, per-user auth/ACL). With modern AI coding tools, implementing and iterating on such a plugin is much faster now, and it can stay flexible for your specific workflow without waiting for core changes.

@fatedier commented on GitHub (Feb 3, 2026): One practical way to solve this today is to build a server-side plugin (similar to fp-multiuser) that keeps a central “user/proxy policy” store and enforces it on frps (e.g., allowed custom domains, bandwidth limits, per-user auth/ACL). With modern AI coding tools, implementing and iterating on such a plugin is much faster now, and it can stay flexible for your specific workflow without waiting for core changes.

gitea-mirror commented

2026-05-05 14:33:29 -06:00

Author

Owner

Copy link

@kzkaram commented on GitHub (Feb 3, 2026):

In fact that is exactly what I did try to do even before finding fp-multiuser :-). I do have a technical background and some coding experience but in areas far removed from Linux and even the use of github. The AI (as you suggest) did attempt to create such a plugin but the process encountered some problems which, all of this being an alien environment to me, I was as yet unable to help it with - something about ' no required module provides package github.com/fatedier/frp/pkg/plugin' at one point. Since I didn't even know if it was a total hallucination didn't purse much further, but now that you indicate it is a viable way then I will revisit and see if I can clear the block.

@kzkaram commented on GitHub (Feb 3, 2026): In fact that is exactly what I did try to do even before finding fp-multiuser :-). I do have a technical background and some coding experience but in areas far removed from Linux and even the use of github. The AI (as you suggest) did attempt to create such a plugin but the process encountered some problems which, all of this being an alien environment to me, I was as yet unable to help it with - something about ' no required module provides package github.com/fatedier/frp/pkg/plugin' at one point. Since I didn't even know if it was a total hallucination didn't purse much further, but now that you indicate it is a viable way then I will revisit and see if I can clear the block.

gitea-mirror commented

2026-05-05 14:33:30 -06:00

Author

Owner

Copy link

@github-actions[bot] commented on GitHub (Feb 18, 2026):

Issues go stale after 14d of inactivity. Stale issues rot after an additional 3d of inactivity and eventually close.

@github-actions[bot] commented on GitHub (Feb 18, 2026): Issues go stale after 14d of inactivity. Stale issues rot after an additional 3d of inactivity and eventually close.

No Branch/Tag specified