[GH-ISSUE #3267] [Feature Request] server plugin op for HTTP CONNECT authentication?

gitea-mirror commented

2026-05-05 13:41:19 -06:00

Owner

Originally created by @lindi2 on GitHub (Jan 23, 2023).
Original GitHub issue: https://github.com/fatedier/frp/issues/3267

Describe the feature request

Background

I'm trying to create a system where embedded devices can expose their SSH service for technicians even when they are behind NAT. It is very important that each device can only register as "device-XYZ" where XYZ is the serial number of the device. It seems I can implement this easily by creating a plugin that handles the "NewProxy" op (or by using the existing fp-multiuser and frp_plugin_allowed_ports plugins).

Feature request

I would like to restrict each technician so that they can access only devices that they are maintaining. Would it be possible to create a new proxy op for handling the HTTP CONNECT in tcpmux?

Here's my current test setup:

# frps.ini
[common]
bind_port = 5001
tcpmux_httpconnect_port = 5002

[plugin.deviceauth]
addr = 127.0.0.1:5003
path = /handler
ops = Login, NewProxy, CloseProxy, Ping, NewWorkConn, NewUserConn

# frpc.ini
[common]
server_addr = 10.5.5.28
server_port = 5001
user = device-123
meta_token = device-123-token

[proxy1]
type = tcpmux
multiplexer = httpconnect
custom_domains = device-123-domain
local_port = 22

Command used to access a device:

ssh -o 'proxycommand socat - PROXY:10.5.5.28:device-123-domain:443,proxyport=5002,proxyauth=technician-1:technician-1-password' device-123

Describe alternatives you've considered

The first alternative that I thought was to run an HTTP reverse proxy in front of frp and handle the authentication there.

I am not very familiar with the frp code base yet to understand what would be the best way to implement this feature.

Affected area

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

Originally created by @lindi2 on GitHub (Jan 23, 2023). Original GitHub issue: https://github.com/fatedier/frp/issues/3267 ### Describe the feature request ### Background I'm trying to create a system where embedded devices can expose their SSH service for technicians even when they are behind NAT. It is very important that each device can only register as "device-XYZ" where XYZ is the serial number of the device. It seems I can implement this easily by creating a plugin that handles the "NewProxy" op (or by using the existing fp-multiuser and frp_plugin_allowed_ports plugins). ### Feature request I would like to restrict each technician so that they can access only devices that they are maintaining. Would it be possible to create a new proxy op for handling the HTTP CONNECT in tcpmux? Here's my current test setup: ``` # frps.ini [common] bind_port = 5001 tcpmux_httpconnect_port = 5002 [plugin.deviceauth] addr = 127.0.0.1:5003 path = /handler ops = Login, NewProxy, CloseProxy, Ping, NewWorkConn, NewUserConn ``` ``` # frpc.ini [common] server_addr = 10.5.5.28 server_port = 5001 user = device-123 meta_token = device-123-token [proxy1] type = tcpmux multiplexer = httpconnect custom_domains = device-123-domain local_port = 22 ``` Command used to access a device: `ssh -o 'proxycommand socat - PROXY:10.5.5.28:device-123-domain:443,proxyport=5002,proxyauth=technician-1:technician-1-password' device-123` ### Describe alternatives you've considered The first alternative that I thought was to run an HTTP reverse proxy in front of frp and handle the authentication there. I am not very familiar with the frp code base yet to understand what would be the best way to implement this feature. ### Affected area - [ ] Docs - [ ] Installation - [ ] Performance and Scalability - [X] Security - [ ] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [ ] Server Plugin - [ ] Extensions - [ ] Others

gitea-mirror

2026-05-05 13:41:19 -06:00

closed this issue
added the
todo
label

gitea-mirror commented

2026-05-05 13:41:24 -06:00

Author

Owner

@fatedier commented on GitHub (Jan 29, 2023):

Maybe we can support httpconnect auth directly

# frpc.ini
[common]
server_addr = 10.5.5.28
server_port = 5001
user = device-123
meta_token = device-123-token

[proxy1]
type = tcpmux
multiplexer = httpconnect
custom_domains = device-123-domain
httpconnect_user = abc
httpconnect_passwd = 123
local_port = 22

WDYT?

@fatedier commented on GitHub (Jan 29, 2023): Maybe we can support httpconnect auth directly ```ini # frpc.ini [common] server_addr = 10.5.5.28 server_port = 5001 user = device-123 meta_token = device-123-token [proxy1] type = tcpmux multiplexer = httpconnect custom_domains = device-123-domain httpconnect_user = abc httpconnect_passwd = 123 local_port = 22 ``` WDYT?

gitea-mirror commented

2026-05-05 13:41:25 -06:00

Author

Owner

@lindi2 commented on GitHub (Jan 29, 2023):

Would that mean that all technicians accessing "proxy1" would be using the same password? Ideally each technician would authenticate using their own password and only the "frps" would see that password. The "frpc" should not know about the passwords of technicians.

@lindi2 commented on GitHub (Jan 29, 2023): Would that mean that all technicians accessing "proxy1" would be using the same password? Ideally each technician would authenticate using their own password and only the "frps" would see that password. The "frpc" should not know about the passwords of technicians.

gitea-mirror commented

2026-05-05 13:41:26 -06:00

Author

Owner

@fatedier commented on GitHub (Jan 30, 2023):

Would that mean that all technicians accessing "proxy1" would be using the same password? Ideally each technician would authenticate using their own password

Combine with route_by_http_user, you can set unique password for each user.

only the "frps" would see that password. The "frpc" should not know about the passwords of technicians.

After we support httpconnect auth, you can change the auth password in server plugin.

Example:

[proxy1]
type = tcpmux
multiplexer = httpconnect
custom_domains = device-123-domain
route_by_http_user = foo
httpconnect_user = foo
httpconnect_passwd = 123
local_port = 22

[proxy2]
type = tcpmux
multiplexer = httpconnect
custom_domains = device-123-domain
route_by_http_user = bar
httpconnect_user = bar
httpconnect_passwd = 234
local_port = 22

If you don't want to set password in frpc, you can omit it and set in your server plugin.

@fatedier commented on GitHub (Jan 30, 2023): > Would that mean that all technicians accessing "proxy1" would be using the same password? Ideally each technician would authenticate using their own password Combine with `route_by_http_user`, you can set unique password for each user. > only the "frps" would see that password. The "frpc" should not know about the passwords of technicians. After we support httpconnect auth, you can change the auth password in server plugin. Example: ```ini [proxy1] type = tcpmux multiplexer = httpconnect custom_domains = device-123-domain route_by_http_user = foo httpconnect_user = foo httpconnect_passwd = 123 local_port = 22 [proxy2] type = tcpmux multiplexer = httpconnect custom_domains = device-123-domain route_by_http_user = bar httpconnect_user = bar httpconnect_passwd = 234 local_port = 22 ``` If you don't want to set password in frpc, you can omit it and set in your server plugin.

gitea-mirror commented

2026-05-05 13:41:26 -06:00

Author

Owner

@fatedier commented on GitHub (Jun 30, 2023):

Closed by https://github.com/fatedier/frp/pull/3345

@fatedier commented on GitHub (Jun 30, 2023): Closed by https://github.com/fatedier/frp/pull/3345

gitea-mirror referenced this issue

2026-05-05 14:45:11 -06:00

[PR #2618] [CLOSED] fix: a negetive number in statistic #4602