gitea-mirror commented

Owner

Copy link

Originally created by @apzc2529 on GitHub (Oct 3, 2025).
Original GitHub issue: https://github.com/fatedier/frp/issues/5009

Describe the feature request

For fp-multiuser, frps requires both:
user = "user"
metadatas.token = "123"

I’d like to run frpc purely via CLI (no INI/TOML). Some single-proxy subcommands expose --metadatas key=value, but behavior seems inconsistent:

stcp (non-visitor)
The CLI accepts --metadatas token=123, but login still fails as if metadata (or user) were empty.

frpc stcp
-n secret_ssh
-i 127.0.0.1 -l 22
-s 1.2.3.4 -P 7000
-u user
--metadatas token=123

Actual logs:
[E] [client/service.go:310] user or meta token can not be empty
[W] [client/service.go:328] connect to server error: user or meta token can not be empty
login to the server failed: user or meta token can not be empty. With loginFailExit enabled, no additional retries will be attempted

stcp visitor
The subcommand does not expose --metadatas, so there’s no way (that I can see) to pass metadatas.token from the CLI at all.

frpc stcp visitor
-n secret_ssh_visitor
--server-name secret_ssh
--bind-addr 127.0.0.1 --bind-port 60022
-s 1.2.3.4 -P 7000
-u user

wanted: --metadatas token=123 <— flag not available here

What I expected

A documented way to pass both user and metadatas.token entirely via CLI for all single-proxy modes (including stcp visitor).

If --metadatas is supported in stcp, it should reach the login step so fp-multiuser auth succeeds.

Questions / Requests

Is there an existing global flag or environment variable that lets stcp visitor carry metadata via CLI (without config files)?

If not, could you:

Add --metadatas support to stcp visitor (and other visitor subcommands if missing), and/or

Provide a global --metadatas key=value that applies to all single-proxy modes, visitor included?

For stcp non-visitor: is the --metadatas flag expected to be honored during login in single-proxy mode? If yes, the failure above might be a bug—please advise.

Environment

frpc: 0.65.0

OS: Ubuntu 22.04 (x86_64)

Mode: single-proxy subcommands (frpc stcp …, frpc stcp visitor …)

Why this matters

In automated / ephemeral environments, we prefer a single one-liner over provisioning config files. fp-multiuser deployments commonly rely on metadatas.token, so CLI parity across subcommands would be very helpful.

Workaround

Using a tiny config just to carry [common] user and [metadatas] token works, but defeats the “pure CLI” goal.

Thanks for maintaining frp! Happy to test patches or provide any extra logs you need.

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 @apzc2529 on GitHub (Oct 3, 2025). Original GitHub issue: https://github.com/fatedier/frp/issues/5009 ### Describe the feature request For fp-multiuser, frps requires both: user = "user" metadatas.token = "123" I’d like to run frpc purely via CLI (no INI/TOML). Some single-proxy subcommands expose --metadatas key=value, but behavior seems inconsistent: stcp (non-visitor) The CLI accepts --metadatas token=123, but login still fails as if metadata (or user) were empty. frpc stcp \ -n secret_ssh \ -i 127.0.0.1 -l 22 \ -s 1.2.3.4 -P 7000 \ -u user \ --metadatas token=123 Actual logs: [E] [client/service.go:310] user or meta token can not be empty [W] [client/service.go:328] connect to server error: user or meta token can not be empty login to the server failed: user or meta token can not be empty. With loginFailExit enabled, no additional retries will be attempted stcp visitor The subcommand does not expose --metadatas, so there’s no way (that I can see) to pass metadatas.token from the CLI at all. frpc stcp visitor \ -n secret_ssh_visitor \ --server-name secret_ssh \ --bind-addr 127.0.0.1 --bind-port 60022 \ -s 1.2.3.4 -P 7000 \ -u user # wanted: --metadatas token=123 <— flag not available here What I expected A documented way to pass both user and metadatas.token entirely via CLI for all single-proxy modes (including stcp visitor). If --metadatas is supported in stcp, it should reach the login step so fp-multiuser auth succeeds. Questions / Requests Is there an existing global flag or environment variable that lets stcp visitor carry metadata via CLI (without config files)? If not, could you: Add --metadatas support to stcp visitor (and other visitor subcommands if missing), and/or Provide a global --metadatas key=value that applies to all single-proxy modes, visitor included? For stcp non-visitor: is the --metadatas flag expected to be honored during login in single-proxy mode? If yes, the failure above might be a bug—please advise. Environment frpc: 0.65.0 OS: Ubuntu 22.04 (x86_64) Mode: single-proxy subcommands (frpc stcp …, frpc stcp visitor …) Why this matters In automated / ephemeral environments, we prefer a single one-liner over provisioning config files. fp-multiuser deployments commonly rely on metadatas.token, so CLI parity across subcommands would be very helpful. Workaround Using a tiny config just to carry [common] user and [metadatas] token works, but defeats the “pure CLI” goal. Thanks for maintaining frp! Happy to test patches or provide any extra logs you need. ### Describe alternatives you've considered _No response_ ### Affected area - [ ] Docs - [ ] Installation - [ ] Performance and Scalability - [ ] Security - [x] User Experience - [ ] Test and Release - [x] Developer Infrastructure - [ ] Client Plugin - [ ] Server Plugin - [ ] Extensions - [ ] Others

gitea-mirror closed this issue

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

gitea-mirror commented

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

Author

Owner

Copy link

@fatedier commented on GitHub (Oct 8, 2025):

Due to CLI limitations in expressing complex hierarchical structures, frpc stcp --metadatas token=123 sets proxy-level metadata, not client-level metadata. Currently, there's no support for configuring client-level metadata via CLI flags (the names conflict with each other).

As a workaround, you might consider writing a custom server plugin (similar to fp-multiuser) that validates using proxy-level metadata instead. This would allow your pure CLI approach to work without config files.

@fatedier commented on GitHub (Oct 8, 2025): Due to CLI limitations in expressing complex hierarchical structures, `frpc stcp --metadatas token=123` sets proxy-level metadata, not client-level metadata. Currently, there's no support for configuring client-level metadata via CLI flags (the names conflict with each other). As a workaround, you might consider writing a custom server plugin (similar to fp-multiuser) that validates using proxy-level metadata instead. This would allow your pure CLI approach to work without config files.

gitea-mirror commented

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

Author

Owner

Copy link

@apzc2529 commented on GitHub (Oct 11, 2025):

OK. Thank you.

@apzc2529 commented on GitHub (Oct 11, 2025): OK. Thank you.

No Branch/Tag specified