Repository navigation
feat(dashboard): edit each forge's access settings - #559
Conversation
There was a problem hiding this comment.
Server side looks right. Forge names are matched against the configured forges before they reach the file name, so there's no path injection. An unknown forge returns 404, and refresh covers every target. The tests cover save, reset, startup and an unknown forge.
One blocking issue, in the dashboard form: stale responses can load one forge's settings under another forge's selector (inline).
Nit: the new sentence in docs/dashboard.md is not wrapped to the file's line width.
CI was still running when I reviewed.
There was a problem hiding this comment.
8d21c3e fixes the stale-response finding. Reads now go through switchMap, the selector is disabled while a save or reset runs, and save/reset skip load() if the forge changed. The docs line is rewrapped. Nothing new in the changed code.
Closes #558
The dashboard's access section now has a forge selector when
LFSX_FORGESnames any. Each forge's allow-list, restricted repositories and anonymous reads are saved, reset and refreshed on their own; a forge nobody changed keeps its environment./-/api/access?forge=<name>(GET, PUT, DELETE); without it, the main forge as before. An unknown name answers 404 and writes nothing..lfsx/access-<name>.jsonbesideaccess.json, and the 30 s refresh reads every forge's file, so all replicas follow.access.rsresolves aTarget(authorizer, environment, file) per request instead of hard-wiring the main forge.flr-selectabove the form, "Main forge" plus each name; switching reloads that forge's settings. Checked on a local demo with a named forge.tests/forge_access.rs): saving a named forge's access changes only that forge and writes only its file; reset brings back its environment; an unknown forge is 404 for GET, PUT and DELETE; a server starting with a saved forge file applies it.docs/dashboard.md,docs/forges.md,docs/api.md.Full server suite, clippy, typecheck and the dashboard build pass locally.