Repository navigation
Improvement/backlog roadmap - #171
Closed
felix-homelab wants to merge 30 commits into
Closed
felix-homelab wants to merge 30 commits into
felix-homelab wants to merge 30 commits into
Conversation
frp-panel pins frp v0.65.0 while upstream frp is at v0.70.1, and this fork had zero divergence from VaalaCat/frp-panel until now. Every upstream-owned file we touch is a permanent, recurring rebase cost -- so concentrate the churn before it starts. internal/frpx/ is a new top-level package upstream does not have, which means it can never produce a rebase conflict. It now owns 100% of the non-config/v1 frp imports (client, server, msg, metrics, metrics/mem, plugin/server, featuregate, validation, config, util/log, client/proxy) plus every call into config/v1 *behavior*. pkg/config/v1 is deliberately NOT wrapped. Type aliases would give zero insulation, and real wrapper structs would break the DB blob format (models/proxy_config.go stores cfg.MarshalJSON()) and the frontend JSON contract. The rule is: wrap behavior, pass data through. Outside frpx, config/v1 remains a direct import in 22 files. Signatures are chosen to be implementable on both v0.65.0 and v0.70.1 so call sites never change again. CompleteProxy keeps a *v1.ClientCommonConfig parameter that frp >= v0.68 no longer needs -- that unused argument is the point: it freezes the body of utils/load.go, the repo's highest-churn conflict point. No behavior change; this is a mechanical import swap still on frp v0.65.0. internal/frpx/doc.go pins the current frp version and lists every upstream symbol depended on, with the file that owns it -- that list is the next bump's checklist.
Nothing in this repository exercised a tunnel. Bumping frp was therefore unverifiable beyond "it compiles", and CI's `go test ./...` step is commented out because services/workerd.TestRunWorker hardcodes /home/coder/... paths and fails outside the original author's container. internal/frpx/tunnel_integration_test.go (build tag: integration) stands up a real frps and a real frpc in one process and pushes real bytes through tcp, udp, http, https, stcp, sudp and tcpmux. It drives configuration through utils.LoadClientConfig with real JSON rather than hand-built structs, so it exercises the production path -- including the Complete() fan-out whose semantics change in frp v0.68. https goes through the https2http plugin with a self-signed cert; tcpmux through an HTTP CONNECT handshake. xtcp is gated behind FRPX_TEST_XTCP because loopback hole punching is unreliable, and one flaky type is how integration suites get disabled and then deleted. The `proxy name correlation` subtest records v0.65 semantics as a baseline: frp v0.68 moved user-prefixing from config completion to the wire layer, so the client-side status lookup key changes from "alice.ssh" to "ssh" while the wire name stays "alice.ssh". That subtest is designed to fail on the bump, with an assertion message telling the reader what to do about it. fork-checks.yml is a new workflow rather than an edit to master-merge-check.yml, for the same conflict-surface reason as frpx. It tracks go.mod via go-version-file, so an frp bump that raises the required Go version does not also require editing CI.
…o docs/feature-matrix
…B group UpdateWorkerLoadBalancerGroup rebuilt the proxy through msg.NewProxy, which carries only the wire subset, and so dropped enabled, localIP, localPort, plugin, healthCheck and transport.proxyProtocolVersion on every update (BUG-08). Mutate the *HTTPProxyConfig in place, leave anything that is not a worker-ingress http proxy untouched, and delete the now-unused frpx.NewProxyMsg so the round-trip cannot come back. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
frp runs FilterClientConfigurers (start[] and per-proxy enabled) only when it builds a service or reloads its own config source; UpdateAllConfigurer takes the slices as given. Every update the master pushes went straight to it, so a proxy switched to enabled: false kept running until the agent restarted (BUG-12). Route all hot updates through frpx.UpdateClientConfigurers, and cover it in the tunnel matrix: the subtest fails without the fix. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
With BUG-12 fixed, an enabled: false proxy is really gone from the agent, so the status lookup misses and the proxy list showed "error". Answer from the master's own record for stopped and disabled proxies, and keep asking the agent for everything else, including unreadable content. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The add buttons in list-input.tsx had no type, which makes them submit buttons inside the RHF forms they are rendered in. In the frpc form, adding a metadata key pushed the whole client config to the agent (BUG-13). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
RebuildProxyConfigFromClient looked the old row up by OriginClientID == <child client id>, which never matches. Every rebuild re-created every row under a new ID, and a stopped row, which the delete spares, was duplicated when its name came back into the config (BUG-14). Look up by ClientID. Existing duplicates collapse on the next rebuild, so no data migration is needed. Tested against sqlite. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
`pnpm test` runs www/test/*.test.mjs on Node's built-in test runner. ts-hooks.mjs resolves the @/ alias and transpiles TypeScript with the project's own compiler, so no test framework is added. Pure modules only; there is no DOM. Works on Node 20 (CI) and 24. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Wire the supportedPlugins prop no caller passed (PLG-05): for example no static_file on https, and no plugins on udp/sudp, which frp ignores. The reasoning per proxy type is in plugins.ts. A plugin already stored on the proxy stays selectable, so opening the form never swaps it out. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
requestHeaders.set on http2http, http2https, https2http and https2https, and enableHTTP2 on the two https ones, which was also missing from the TS mirror (PLG-04). https2https inherits both through the https2http form. There is no responseHeaders: frp's plugin options have none, and the strict decoder would reject the whole config if a form sent it. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The master and the Server agent each carried an inline copy of "drop every multiuser entry, append the panel's". Move it into one tested helper, conf.WithFRPsAuthPlugin, before user plugin entries become editable. No behaviour change. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
New "HTTP plugins" section in the frps form (FS-11). The panel's multiuser entry is shown read-only and re-attached by the backend; zod rejects a user entry by that name, duplicate names, and empty or unsupported ops. Ticking Login warns that such a plugin runs before the panel's authentication and can reject or rewrite every login. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Add ClientVersion.FrpVersion, filled from frpx.Version() and printed by `version`. The master had no way to learn which frp an agent runs: the panel GitVersion says nothing about it. Agents that predate the field send nothing and must be treated as too old (CAP-01). Regenerated with protoc 3.21.11, protoc-gen-go 1.36.8, protoc-gen-go-grpc 1.5.1 and protobuf-ts 2.9.3, the versions the existing files were built with; every unchanged file came out byte-identical. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The frpc form offers v2 when the client agent and the server agent both report frp >= v0.69, and biz/master/client/wire_protocol.go re-checks it on every save (BUMP-07): always refused for an external frps, fail closed for an agent that is offline or too old to report its version, and nothing is pinged unless v2 is requested. Values other than v1/v2 are now rejected before they can reach an agent. Trade-off: a client set to v2 can only be saved while both agents are online. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
`go run ./hack/frpdrift` lists frp config field paths added or removed since the last review, against hack/frpdrift/known.txt (428 paths at frp v0.70.1). The check is a review prompt and stays out of CI; its tests do not, and they pin facts FEATURE-MATRIX.md relies on. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
FEATURE-MATRIX.md has always listed pnpm lint && pnpm build as part of the fork gate, but the workflow only had a Go job. Add a www job (pnpm test, pnpm lint, next build), and run the biz, services/dao and hack tests as well. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Section 3 still said four proxy types had no form and visitors had no UI, both untrue since v0.10.1. Also cover the hot-update subtest, the extended test list and the frp version gates to re-check on a bump. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Move BUG-08, PLG-04, PLG-05, FS-11 and BUMP-07 to the "closed" notes and record BUG-12 to BUG-14. Correct the PLG-04 scope (plugins have no responseHeaders), stale line references and the Verification section, and record why BUMP-04 is recommended as won't-do. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
ROADMAP.md orders the FEATURE-MATRIX.md backlog into milestones, tracks the status of each item and its verification, and lists the decisions still open (BUG-09, BUMP-04, REL-01). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
One section per release tag (v0.10.0, v0.10.1, Unreleased), plus the fork point (upstream v0.1.37) and the cumulative differences to upstream. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The release step now uses the tag's CHANGELOG.md section as the release body, with relative .md links made absolute, and a tag without a section fails before anything is built or published. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
A plain-language "About this fork" section: what differs from upstream, that version numbers are the fork's own, that Master, Servers and Clients should come from this fork together, and that install scripts and in-app upgrades still fetch upstream builds for now. Short note in README_zh.md. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
actionlint flags setup-go@v4 (copied verbatim from upstream's tag workflow) as running on a runner GitHub Actions no longer supports. fork-checks.yml already uses v5; the go-version input is unchanged. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Upstream builds its images with ko but pushes them to docker.io/vaalacat using Docker Hub secrets this fork does not have, so the fork published none (REL-04). Build them the same way -- ko with .ko.yaml (every platform alpine ships) and .ko.workerd.yaml -- and push to ghcr.io/<owner>/<repo> with the job's own token: <tag>, latest, <tag>-workerd and latest-workerd. The step runs after the binaries are published, so an image problem cannot hold back a release. OCI labels link the package to the repository. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Name the GHCR image and its tags in the changelog and both READMEs, note that images start with the first release after v0.10.1, and track the change as REL-04 in the roadmap, including the one thing to check after the first push: the package's visibility. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.