pastilhas
2e8ec845c8
The word meant four different things in this repo, not the three the offscale
doc records:
1. the permission registry → RENAMED here
2. $OFFICER_ROOT/capabilities/ items → kept; this is what capabilities are
3. sidecar routing keys → step 3, becoming `handles`
4. Lightning wallet features → kept; a domain term, and on the wire
to the mobile apps
The fourth was not in the doc and a global find-and-replace would have broken
the mobile wallet, which reads `{ kind, capabilities: Capability[] }` from the
wallet sidecar. So this renamed against an explicit file allowlist rather than
by sweeping the tree, and `CapabilityPage.tsx` — the UI for the item store, and
correctly named already — was left alone.
Moved: servers/capabilities/ → servers/permissions/, capability-gate.ts →
permission-gate.ts, users/capabilities-routes.ts → permissions-routes.ts,
hooks/useCapabilities.ts → usePermissions.ts. Identifiers follow.
Three breaks the typechecker could not see, all found by exercising it live.
The route paths moved with the prose sweep, so the server served
/user/permissions while the frontend still called /user/capabilities. A 404 on
every page load, and tsgo clean throughout.
The response FIELD moved too. `client.get<SelfPermissions>()` is an unchecked
cast, so `data.capabilities` became `undefined` at runtime with no compile
error — `can()` would have answered "no" to everything and the dock would have
emptied itself.
And the grants list was passed straight out of the database, so it arrived as
`{ role, capability, level }` while the screen read `grant.permission`. Every
role would have rendered as holding nothing. It is now mapped in the route:
the wire says `permission`, the column still says `capability`, and step 2
therefore changes nothing any client can see.
The stale react-query keys were the quiet one: two files still invalidated
['self-capabilities'] after the hook moved to ['self-permissions'], so
installing a plugin would have silently stopped refreshing the dock.
The database is untouched — `role_capabilities` and its `capability` column are
step 2, and the two call sites that cross that boundary say so in a comment.
Round-tripped the 9 live grants through the admin endpoint to prove the PUT
contract survived: 9 before, 9 after, Member's three intact.
Also reverted prettier churn on five landing-page files that a broad --write
picked up. Second time today; the lesson is not sticking.
tsgo clean. 797 tests, 787 pass, same 7 pre-existing failures — two of which
now read "path → permission" rather than "path → capability".
37 lines
2.0 KiB
TypeScript
37 lines
2.0 KiB
TypeScript
import { Navigate, useLocation } from 'react-router';
|
|
import { usePermissions } from 'hooks/usePermissions';
|
|
|
|
// A screen exists only if this server has the thing behind it and this account may reach it. Otherwise the
|
|
// path is treated exactly as an unknown one: redirect home, same as App.tsx's `path="*"`.
|
|
//
|
|
// ── Why a redirect and not an explanation ──
|
|
//
|
|
// The first version of this rendered a panel saying "Music is not installed" with a link to the app store,
|
|
// on the reasoning that a redirect erases what you asked for. That was wrong, and the owner's correction is
|
|
// the better principle: a naked platform should not know about a sidecar it does not have. Explaining the
|
|
// absence of Music is the app describing a feature that, as far as this server is concerned, does not exist —
|
|
// and it leaks the whole catalogue of what could be installed to every member who types a URL.
|
|
//
|
|
// So "no such page" is the honest answer, and it is the same answer for a member without a grant, for an
|
|
// owner whose sidecar is not installed, and for a typo. One behaviour, nothing disclosed.
|
|
//
|
|
// This is still a courtesy rather than the lock — every one of these routes is refused server-side too. What
|
|
// it stops is the app offering a door it will then slam.
|
|
//
|
|
// ── What this is NOT ──
|
|
//
|
|
// Routes are still declared in App.tsx for every screen, and this hides the ones that should not resolve. The
|
|
// end state the owner described is different and better: routes REGISTERED from the manifests of installed
|
|
// sidecars, so an uninstalled feature has no route to hide. The manifests already exist (`plugins`, carrying
|
|
// `rootRoute` and `routes`) and the dock is already built from them; the router is not, yet.
|
|
|
|
export function RouteGate({ children }: { children?: React.ReactNode }) {
|
|
const { pathname } = useLocation();
|
|
const { denialReason } = usePermissions();
|
|
|
|
// `replace`, so Back does not bounce between the denied path and home.
|
|
if (denialReason(pathname)) return <Navigate to="/" replace />;
|
|
|
|
return <>{children}</>;
|
|
}
|