[GH-ISSUE #2776] [Feature Request] administer the client via REST #2222

Closed
opened 2026-05-05 13:25:48 -06:00 by gitea-mirror · 2 comments
Owner

Originally created by @penguine on GitHub (Jan 24, 2022).
Original GitHub issue: https://github.com/fatedier/frp/issues/2776

Describe the feature request

to administer the client from outside via REST:

Always start the client and its dashboard before connecting to the server.
start option: -noserver
only the dashboard is accessible, all other actions are initiated via REST
Originally created by @penguine on GitHub (Jan 24, 2022). Original GitHub issue: https://github.com/fatedier/frp/issues/2776 ### Describe the feature request to administer the client from outside via REST: Always start the client and its dashboard before connecting to the server. start option: -noserver only the dashboard is accessible, all other actions are initiated via REST
gitea-mirror 2026-05-05 13:25:48 -06:00
Author
Owner

@penguine commented on GitHub (Jan 24, 2022):

I have achieved that the dashboard is starting first and without a server connection with this workaround in the client/service.go:

func (svr *Service) Run() error {
xl := xlog.FromContextSafe(svr.ctx)

    // start dashboard first, a fast hack
if svr.cfg.AdminPort != 0 {
	// Init admin server assets

	assets.Load(svr.cfg.AssetsDir)

	address := net.JoinHostPort(svr.cfg.AdminAddr, strconv.Itoa(svr.cfg.AdminPort))
	err := svr.RunAdminServer(address)
	if err != nil {
		log.Warn("run admin server error: %v", err)
	}
	log.Info("admin server listen on %s:%d", svr.cfg.AdminAddr, svr.cfg.AdminPort)
           // set to nil
	ctl := NewControl(svr.ctx, svr.runID, nil, nil, svr.cfg, svr.pxyCfgs, svr.visitorCfgs, svr.serverUDPPort, svr.authSetter)
	// [visitor_manager.go:60] gracefully shutdown visitor manager
	ctl.Run()
	svr.ctlMu.Lock()
	svr.ctl = ctl
	svr.ctlMu.Unlock()
}

// ***** login to frps 9.1.22 ***********

for {

	conn, session, err := svr.login()
	if err != nil {
		xl.Warn("login to server failed: %v", err)

		// if login_fail_exit is true, just exit this program
		// otherwise sleep a while and try again to connect to server
		if svr.cfg.LoginFailExit {
			return err
		}
		time.Sleep(10 * time.Second)
	} else {
		// login success
		ctl := NewControl(svr.ctx, svr.runID, conn, session, svr.cfg, svr.pxyCfgs, svr.visitorCfgs, svr.serverUDPPort, svr.authSetter)
		ctl.Run()
		svr.ctlMu.Lock()
		svr.ctl = ctl
		svr.ctlMu.Unlock()
		break
	}
}
go svr.keepControllerWorking()

<-svr.ctx.Done()

return nil
 }
<!-- gh-comment-id:1020332896 --> @penguine commented on GitHub (Jan 24, 2022): I have achieved that the dashboard is starting first and without a server connection with this workaround in the client/service.go: func (svr *Service) Run() error { xl := xlog.FromContextSafe(svr.ctx) // start dashboard first, a fast hack if svr.cfg.AdminPort != 0 { // Init admin server assets assets.Load(svr.cfg.AssetsDir) address := net.JoinHostPort(svr.cfg.AdminAddr, strconv.Itoa(svr.cfg.AdminPort)) err := svr.RunAdminServer(address) if err != nil { log.Warn("run admin server error: %v", err) } log.Info("admin server listen on %s:%d", svr.cfg.AdminAddr, svr.cfg.AdminPort) // set to nil ctl := NewControl(svr.ctx, svr.runID, nil, nil, svr.cfg, svr.pxyCfgs, svr.visitorCfgs, svr.serverUDPPort, svr.authSetter) // [visitor_manager.go:60] gracefully shutdown visitor manager ctl.Run() svr.ctlMu.Lock() svr.ctl = ctl svr.ctlMu.Unlock() } // ***** login to frps 9.1.22 *********** for { conn, session, err := svr.login() if err != nil { xl.Warn("login to server failed: %v", err) // if login_fail_exit is true, just exit this program // otherwise sleep a while and try again to connect to server if svr.cfg.LoginFailExit { return err } time.Sleep(10 * time.Second) } else { // login success ctl := NewControl(svr.ctx, svr.runID, conn, session, svr.cfg, svr.pxyCfgs, svr.visitorCfgs, svr.serverUDPPort, svr.authSetter) ctl.Run() svr.ctlMu.Lock() svr.ctl = ctl svr.ctlMu.Unlock() break } } go svr.keepControllerWorking() <-svr.ctx.Done() return nil }
Author
Owner

@github-actions[bot] commented on GitHub (Feb 24, 2022):

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

<!-- gh-comment-id:1049363751 --> @github-actions[bot] commented on GitHub (Feb 24, 2022): Issues go stale after 30d of inactivity. Stale issues rot after an additional 7d of inactivity and eventually close.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/frp#2222
No description provided.