[GH-ISSUE #2487] Exit if login fails while reconnecting

gitea-mirror commented

2026-05-05 13:16:17 -06:00

Owner

Originally created by @jordemort on GitHub (Jul 19, 2021).
Original GitHub issue: https://github.com/fatedier/frp/issues/2487

I would like an option to make frpc to exit when it fails to reconnect.

I thought that login_fail_exit would do this, but it does not.
I submitted a PR to make login_fail_exit do this, but what I want is not actually the intended behavior of login_fail_exit https://github.com/fatedier/frp/pull/2483

I would add a new option (maybe reconnect_login_fail_exit?) that would make frpc exit when it fails to login while reconnecting.

Application scenarios of this function

We need to authenticate our frpc clients when they connect to frps. We cannot use a single shared token for this purpose, and we do not want to maintain the infrastructure needed to support OIDC authentication. Instead, we have implemented our own authentication system using a server plugin for Login.

We have a script that generates a JWT and stores it in the environment, and then starts frpc. Our frpc.ini contains the following line:

meta_jwt = {{ .Envs.JWT }}

When the client tries to log in, the JWT is passed over to our server plugin, which validates it and allows the login to succeed.

However, the JWT is only valid for a short time. When frpc attempts to reconnect, it uses the same JWT as when it was initially started. The JWT is now expired. Our server plugin rejects the login and our tunnel never comes back up, because frpc just keeps trying with the same expired token.

Instead of retrying forever, we would like a way to make frpc exit when the login fails when reconnecting. Then our script can regenerate the JWT and restart frpc, and it will be able to connect again.

Originally created by @jordemort on GitHub (Jul 19, 2021). Original GitHub issue: https://github.com/fatedier/frp/issues/2487  I would like an option to make `frpc` to exit when it fails to reconnect.  - I thought that `login_fail_exit` would do this, but it does not. - I submitted a PR to make `login_fail_exit` do this, but what I want is not actually the intended behavior of `login_fail_exit` https://github.com/fatedier/frp/pull/2483  I would add a new option (maybe `reconnect_login_fail_exit`?) that would make `frpc` exit when it fails to login while reconnecting.  **Application scenarios of this function** We need to authenticate our `frpc` clients when they connect to `frps`. We cannot use a single shared token for this purpose, and we do not want to maintain the infrastructure needed to support OIDC authentication. Instead, we have implemented our own authentication system using a [server plugin for Login](https://github.com/fatedier/frp/blob/dev/doc/server_plugin.md#login). We have a script that generates a JWT and stores it in the environment, and then starts `frpc`. Our `frpc.ini` contains the following line: ``` meta_jwt = {{ .Envs.JWT }} ``` When the client tries to log in, the JWT is passed over to our server plugin, which validates it and allows the login to succeed. However, the JWT is only valid for a short time. When `frpc` attempts to reconnect, it uses the same JWT as when it was initially started. The JWT is now expired. Our server plugin rejects the login and our tunnel never comes back up, because `frpc` just keeps trying with the same expired token. Instead of retrying forever, we would like a way to make `frpc` exit when the login fails when reconnecting. Then our script can regenerate the JWT and restart `frpc`, and it will be able to connect again.

gitea-mirror

2026-05-05 13:16:17 -06:00

closed this issue
added the
proposal
label

gitea-mirror commented

2026-05-05 13:16:20 -06:00

Author

Owner

@jordemort commented on GitHub (Jul 19, 2021):

@fatedier - I am willing to try and make a PR to implement this, if you think it is something you would accept. My Go skills are not very sharp, but I think I can probably handle it.

@jordemort commented on GitHub (Jul 19, 2021): @fatedier - I am willing to try and make a PR to implement this, if you think it is something you would accept. My Go skills are not very sharp, but I think I can probably handle it.

gitea-mirror commented

2026-05-05 13:16:21 -06:00

Author

Owner

@fatedier commented on GitHub (Jul 20, 2021):

It's not an elegant way to let frpc exit for each login fail reason such as network error or other temporary error.

I have considered add a paramter like permanentError in LoginResponse so frpc can exit when it receives a permanent error. However, i still wonder if we should do that. In which scenarios users want to stop frpc or just keep it running. I think it's a strange behavior so i don't want to add this feature.

What's your need seems a way to refresh token but we havn't provide this way. You key demand is not to stop frpc.

How about providing a new API to show frpc status so you can decide if stopping frpc.

Or maybe we should also consider to extend auth module.

@fatedier commented on GitHub (Jul 20, 2021): It's not an elegant way to let frpc exit for each login fail reason such as network error or other temporary error. I have considered add a paramter like `permanentError` in LoginResponse so frpc can exit when it receives a permanent error. However, i still wonder if we should do that. In which scenarios users want to stop frpc or just keep it running. I think it's a strange behavior so i don't want to add this feature. What's your need seems a way to refresh token but we havn't provide this way. You key demand is not to stop frpc. How about providing a new API to show frpc status so you can decide if stopping frpc. Or maybe we should also consider to extend auth module.

gitea-mirror commented

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

Author

Owner

@jordemort commented on GitHub (Jul 20, 2021):

I have considered add a paramter like permanentError in LoginResponse so frpc can exit when it receives a permanent error. However, i still wonder if we should do that. In which scenarios users want to stop frpc or just keep it running. I think it's a strange behavior so i don't want to add this feature.

Having a way for a login plugin to indicate permanentError (do not try to reconnect) would be ideal for us. This would be even better than reconnect_login_fail_exit for our use case.

How about providing a new API to show frpc status so you can decide if stopping frpc.

I do not like this solution as much. The implementation would be much more complicated. We would need another piece of software that periodically checks frpc and determines if it has failed due to an expired token. This introduces several other moving parts that might possibly fail (connecting to the API, properly processing the results, sending the restart signal.) Compare to our current solution, where we have a simple shell script that systemd restarts whenever it exits.

Or maybe we should also consider to extend auth module.

If this does not allow for a permanentError I don't understand how it would be much different from the existing Login plugin.

The assumption in the "reconnect forever" loop that I've violated with my plugin is that if login succeeded once, then login can succeed again using the same set of credentials. So permanentError seems like the best solution to me, so that I can tell frpc "no, stop trying, this will never work"

@jordemort commented on GitHub (Jul 20, 2021): > I have considered add a paramter like permanentError in LoginResponse so frpc can exit when it receives a permanent error. However, i still wonder if we should do that. In which scenarios users want to stop frpc or just keep it running. I think it's a strange behavior so i don't want to add this feature. Having a way for a login plugin to indicate `permanentError` (do not try to reconnect) would be ideal for us. This would be even better than `reconnect_login_fail_exit` for our use case. > How about providing a new API to show frpc status so you can decide if stopping frpc. I do not like this solution as much. The implementation would be much more complicated. We would need another piece of software that periodically checks `frpc` and determines if it has failed due to an expired token. This introduces several other moving parts that might possibly fail (connecting to the API, properly processing the results, sending the restart signal.) Compare to our current solution, where we have a simple shell script that systemd restarts whenever it exits. > Or maybe we should also consider to extend auth module. If this does not allow for a `permanentError` I don't understand how it would be much different from the existing `Login` plugin. The assumption in the "reconnect forever" loop that I've violated with my plugin is that if login succeeded once, then login can succeed again using the same set of credentials. So `permanentError` seems like the best solution to me, so that I can tell `frpc` "no, stop trying, this will never work"

gitea-mirror commented

2026-05-05 13:16:23 -06:00

Author

Owner

@fatedier commented on GitHub (Jul 21, 2021):

I dont't want to change the architecture that frpc is a long running process and not exit until a manual stop or critical bug. This will add more complexity and it's not the fundamental demand.

We can try to support more auth methods to allow you refresh your tokens without restarting frpc itself. We can study more from other open sources to find a appropriate way.

@fatedier commented on GitHub (Jul 21, 2021): I dont't want to change the architecture that frpc is a long running process and not exit until a manual stop or critical bug. This will add more complexity and it's not the fundamental demand. We can try to support more auth methods to allow you refresh your tokens without restarting frpc itself. We can study more from other open sources to find a appropriate way.

gitea-mirror commented

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

Author

Owner

@jordemort commented on GitHub (Jul 21, 2021):

@fatedier Hm, what if frpc had a client plugin interface, similar or even identical to the server plugin interface? frpc could pass requests to a plugin and the plugin could direct frpc to modify the request before sending it to the server. Then I could build a plugin that always supplies frpc with a fresh JWT.

@jordemort commented on GitHub (Jul 21, 2021): @fatedier Hm, what if frpc had a client plugin interface, similar or even identical to the server plugin interface? frpc could pass requests to a plugin and the plugin could direct frpc to modify the request before sending it to the server. Then I could build a plugin that always supplies frpc with a fresh JWT.

gitea-mirror commented

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

Author

Owner

@fatedier commented on GitHub (Jul 21, 2021):

@fatedier Hm, what if frpc had a client plugin interface, similar or even identical to the server plugin interface? frpc could pass requests to a plugin and the plugin could direct frpc to modify the request before sending it to the server. Then I could build a plugin that always supplies frpc with a fresh JWT.

It's an optional plan. I want to learn more about this field and dicuss later. Let this issue open to trace this proposal.

@fatedier commented on GitHub (Jul 21, 2021): > @fatedier Hm, what if frpc had a client plugin interface, similar or even identical to the server plugin interface? frpc could pass requests to a plugin and the plugin could direct frpc to modify the request before sending it to the server. Then I could build a plugin that always supplies frpc with a fresh JWT. It's an optional plan. I want to learn more about this field and dicuss later. Let this issue open to trace this proposal.

gitea-mirror commented

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

Author

Owner

@jordemort commented on GitHub (Sep 13, 2021):

@fatedier Any further thoughts on enabling this? We're still carrying the custom patch from my old PR in our build.

@jordemort commented on GitHub (Sep 13, 2021): @fatedier Any further thoughts on enabling this? We're still carrying the custom patch from my old PR in our build.

gitea-mirror commented

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

Author

Owner

@fatedier commented on GitHub (Nov 6, 2025):

Further updates will be tracked in https://github.com/fatedier/frp/issues/5045

@fatedier commented on GitHub (Nov 6, 2025): Further updates will be tracked in https://github.com/fatedier/frp/issues/5045

Rows
Columns

[GH-ISSUE #2487] Exit if login fails while reconnecting #1972