[GH-ISSUE #2688] [Feature Request] subdomain restriction

gitea-mirror commented

2026-05-05 13:22:50 -06:00

Owner

Originally created by @hons82 on GitHub (Dec 3, 2021).
Original GitHub issue: https://github.com/fatedier/frp/issues/2688

Describe the feature request

I'd like to restrict the subdomains a client is allowed to register. The idea behind is that I' like to specify on the server that client1 is allowed to open for instance cl1 (aka cl1.mydomain.com) and client2 is alowed to open cl2 and client2 (could be a regex or a list, whatever is easier)

[cl2]
type = http
local_ip = 127.0.0.1
local_port = 8080
subdomain = cl2
# The registration token
meta_client_id = abcd1234

[client2]
type = http
local_ip = 127.0.0.1
local_port = 8081
subdomain = client2
# The registration token
meta_client_id = abcd1234

On the server I'd then need to specify a path to a file, or a REST service that gets as parameters cl2 and abcd1234 and can then check if that combination is allowed.

I hope it is clear what I'm looking for, otherwise please do not hesitate to ask.

Do you see a chance to implement such a functionality as plugin? In that case I could try to implement it myself

Describe alternatives you've considered

I'd like to offer this functionality to my clients, so I'd need to ensure that one client is not hijacking the connection of another client, so I need such a functionality and I did not find a feature like this in the docs.
But as said, I could help with the implementation if possible

Affected area

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

Originally created by @hons82 on GitHub (Dec 3, 2021). Original GitHub issue: https://github.com/fatedier/frp/issues/2688 ### Describe the feature request I'd like to restrict the subdomains a client is allowed to register. The idea behind is that I' like to specify on the server that client1 is allowed to open for instance `cl1` (aka `cl1.mydomain.com`) and client2 is alowed to open `cl2` and `client2` (could be a regex or a list, whatever is easier) ``` [cl2] type = http local_ip = 127.0.0.1 local_port = 8080 subdomain = cl2 # The registration token meta_client_id = abcd1234 [client2] type = http local_ip = 127.0.0.1 local_port = 8081 subdomain = client2 # The registration token meta_client_id = abcd1234 ``` On the server I'd then need to specify a path to a file, or a REST service that gets as parameters `cl2` and `abcd1234` and can then check if that combination is allowed. I hope it is clear what I'm looking for, otherwise please do not hesitate to ask. Do you see a chance to implement such a functionality as plugin? In that case I could try to implement it myself ### Describe alternatives you've considered I'd like to offer this functionality to my clients, so I'd need to ensure that one client is not hijacking the connection of another client, so I need such a functionality and I did not find a feature like this in the docs. But as said, I could help with the implementation if possible ### Affected area - [ ] Docs - [ ] Installation - [ ] Performance and Scalability - [X] Security - [X] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [ ] Server Plugin - [ ] Extensions - [ ] Others

gitea-mirror

2026-05-05 13:22:50 -06:00

closed this issue
added the
lifecycle/stale
label

gitea-mirror commented

2026-05-05 13:22:53 -06:00

Author

Owner

@fatedier commented on GitHub (Dec 3, 2021):

https://github.com/fatedier/frp/blob/dev/doc/server_plugin.md

You can try server plugin.

@fatedier commented on GitHub (Dec 3, 2021): https://github.com/fatedier/frp/blob/dev/doc/server_plugin.md You can try server plugin.

gitea-mirror commented

2026-05-05 13:22:54 -06:00

Author

Owner

@hons82 commented on GitHub (Dec 6, 2021):

That looks promising... I wasn't aware of that.
I'll try that.

@hons82 commented on GitHub (Dec 6, 2021): That looks promising... I wasn't aware of that. I'll try that.

gitea-mirror commented

2026-05-05 13:22:55 -06:00

Author

Owner

@github-actions[bot] commented on GitHub (Jan 6, 2022):

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

@github-actions[bot] commented on GitHub (Jan 6, 2022): Issues go stale after 30d of inactivity. Stale issues rot after an additional 7d of inactivity and eventually close.