mirror of
https://github.com/supabase/supabase.git
synced 2026-10-16 06:39:09 +03:00
The permission scope map previously flattened every `x-fga-permissions` annotation into a single conjunctive scope list, turning OR-alternatives (e.g. development vs production branching on `GET /v1/.../branches`) into impossible AND requirements. EndpointMap and McpMap now store ScopeGroupAlternatives (string[][]) verbatim, and an item is enabled when ALL scopes of at least ONE group are granted — matching how the mgmt-api FGA guard actually evaluates the annotation. Edge cases follow plain DNF semantics: `[[]]` (one empty group) is ungated and callable by any token, `[]` (no groups) is satisfied by nobody, and endpoints with unusable annotations are dropped rather than recorded as ungated. The MCP tool map is rewritten as a direct audit of the Management API endpoint each tool's handler in @supabase/mcp-server-supabase actually calls, with the endpoint named above every entry for re-auditing. The old two-hop derivation (tool -> legacy OAuth scope bundle -> FGA permissions) expanded coarse bundles into conjunctions of permissions the tool never uses, hiding tools from tokens that could genuinely call them. The map now covers the full tool registry, including ungated tools (search_docs, get_project_url, get_cost, confirm_cost), and a new test diffs its keys against the installed package's tool schemas so a dependency bump that adds or drops a tool fails CI by name. buildAPIPermissionScopeMap now fetches the v1/v2 specs in parallel and indexes them in one pass (their path prefixes can't collide), replacing the lodash mergeWith custom-merger, and deep-clones the module-level tool mapping so callers can't mutate state that outlives the request.
Writing components
Where to create your components
- For components that declare the general structure and layout of a page:
/components/layouts/xxx
- For components that are tightly coupled to a specific interface:
/components/interfaces/xxx
- For components that are meant to be reusable across multiple pages:
/components/ui/xxx
- Note: We're gradually moving files out of the
to-be-cleanedfolder into the respective folders as we refactor
Component structure
- If a component has constants and utility methods that are tightly coupled to itself, keep them close to the component and enclose them in a folder with an
index.tsxas an entry point - Otherwise it can just be a file on its own
- For example:
-
components/ui - SampleComponentA - SampleComponentA.tsx - SampleComponentA.constants.ts - SampleComponentA.utils.ts - SampleComponentA.types.ts - index.ts - SampleComponentB.tsx
-
Template for building components
// Declare the prop types of your component
interface ComponentAProps {
sampleProp: string
}
// Name your component accordingly — use a named export, not a default export
export const ComponentA = ({ sampleProp }: ComponentAProps) => {
return <div>ComponentA: {sampleProp}</div>
}