Skip to content

feat(extensibility): FUNC-577 - Gates provide composable handlers#65

Draft
johnstonmatt wants to merge 47 commits into
mainfrom
FUNC-577/gates-core
Draft

feat(extensibility): FUNC-577 - Gates provide composable handlers#65
johnstonmatt wants to merge 47 commits into
mainfrom
FUNC-577/gates-core

Conversation

@johnstonmatt
Copy link
Copy Markdown
Contributor

@johnstonmatt johnstonmatt commented May 15, 2026

// example-function.ts
import { withSupabase } from "@supabase/server";
import { withFeatureFlag } from "@supabase/server/gates/feature-flag";
import { withRateLimit } from "@supabase/server/gates/rate-limit";

export default {
  fetch: withSupabase(
    { allow: "user" }, // ctx.supabase, ctx.userClaims
    withFeatureFlag(
      {
        name: "beta-search",
        evaluate: (req) => req.headers.get("x-beta") === "1",
      },
      withRateLimit(
        {
          limit: 60,
          windowMs: 60_000,
          key: (req) => req.headers.get("cf-connecting-ip") ?? "anon",
        },
        async (_req, ctx) => {
          // ctx.userClaims  ← withSupabase
          // ctx.supabase    ← withSupabase  (user-scoped, RLS applies)
          // ctx.featureFlag ← withFeatureFlag
          // ctx.rateLimit   ← withRateLimit
          const { data } = await ctx.supabase.from("reports").select();
          return Response.json({
            user: ctx.userClaims!.id,
            variant: ctx.featureFlag.variant,
            remaining: ctx.rateLimit.remaining,
            data,
          });
        },
      ),
    ),
  ),
};

This pull request introduces a new extensibility system called gates to the @supabase/server package, enabling users and third-party authors to add reusable middleware-like wrappers (such as feature flags, rate limiting, etc.) to fetch handlers. The PR also adds documentation and updates package exports to support this new system, including a built-in feature flag gate as an example. Below are the most important changes:

Gates System Introduction & Documentation

  • Added a comprehensive section to the README.md explaining gates: what they are, how to use them, and where to find documentation and examples. This includes usage patterns, TypeScript inference details, and links to authoring guides.
  • Added a new src/core/gates/README.md with detailed documentation for gate authors and consumers, including type safety guarantees, composition rules, and authoring patterns using the new defineGate primitive.

Exports and Packaging

  • Updated package.json and jsr.json to export the new @supabase/server/core/gates (gate authoring primitives) and @supabase/server/gates/feature-flag (the worked example gate), making them available for import in user projects. [1] [2] [3]

Documentation and Discoverability

  • Expanded the exports and documentation tables in README.md to list the new gate-related exports and provide direct links to documentation for extending handlers, writing custom gates, and using the feature flag gate. [1] [2]

Changelog

  • Minor formatting fix in CHANGELOG.md for consistency.

Notes

  • there are many other Gates that have been developed internally which we may choose to provide here later

@johnstonmatt johnstonmatt requested review from a team as code owners May 15, 2026 10:06
@pkg-pr-new
Copy link
Copy Markdown

pkg-pr-new Bot commented May 15, 2026

Open in StackBlitz

npm i https://pkg.pr.new/@supabase/server@65

commit: 9a31dfb

@johnstonmatt johnstonmatt marked this pull request as draft May 15, 2026 10:10
johnstonmatt and others added 22 commits May 19, 2026 22:45
JSR rejects destructured exports and exports without explicit type
annotations in the public API. Return `withSupabase` directly from
`defineAdapter` (instead of `{ withSupabase }`) and annotate each
adapter's exported `withSupabase` with `AdapterWithSupabase<...>`.
…ps://github.com/supabase/server into FUNC-577/gates-core

# Conflicts:
#	src/adapters/elysia/plugin.test.ts
#	src/adapters/elysia/plugin.ts
#	src/adapters/h3/middleware.test.ts
#	src/adapters/h3/middleware.ts
#	src/adapters/hono/middleware.test.ts
#	src/adapters/hono/middleware.ts
#	src/core/adapters/define-adapter.test.ts
#	src/core/adapters/define-adapter.ts
Brings the NestJS adapter under the same `defineAdapter` factory used by
Hono, H3, and Elysia. The one-arg guard class behavior is unchanged; the
two-arg dual-mode handler (`Request | ExecutionContext`) is added for
parity with the other adapters.

NestJS intentionally omits `getExistingContext` — guards run in
global → controller → handler order, so a handler-level guard must
always re-evaluate to override what an outer guard set.
PR #71 (on FUNC-655/defineAdapter-for-uniform-integrations) is the
source of truth for the `defineAdapter` API and lands first. Match its
shape on this branch so that once #71 merges to main, no breaking
change ripples through to gates-core consumers:

- `defineAdapter(spec)` returns the overloaded `withSupabase` function
  directly (was: `{ withSupabase }`).
- Adapters annotate the export explicitly:
  `export const withSupabase: AdapterWithSupabase<Ctx, M> = defineAdapter<...>({...})`
  (was: `export const { withSupabase } = defineAdapter<...>({...})`).

The annotation duplication is the price of JSR slow-type compatibility
without the wrapping object. Same trade-off PR #71 already made; this
just keeps the public surface uniform across branches.
Adds the bridging primitives that let gates from `@supabase/server/gates/*`
work in NestJS's decorator/guard model rather than only the fetch-handler
nesting form.

- `defineGate` now exposes the gate's `key` and `run` builder as readable
  properties on the returned factory. Existing call sites are unchanged;
  this only adds metadata.
- `asGuard(gate, config)` returns a `CanActivate` guard class that drives
  the gate's check phase. Upstream ctx is built by merging
  `req.supabaseContext` (Supabase fields) and `req.gateContext` (peer bag
  for gate contributions), so gates with `In = { supabase, userClaims }`
  and gates with `In = { featureFlag }` both find their prereqs without
  either bag bleeding into the other.
- On short-circuit `Response`, status + body propagate as `HttpException`
  (JSON body parsed when content-type matches, falls back to text).
- On contribution, the gate's `{ [key]: value }` is merged into
  `req.gateContext` — never written into `req.supabaseContext`.
- `gateCtx(gate)` returns a typed param decorator that reads the gate's
  contribution from `req.gateContext`. Supports optional sub-key access
  (`@FlagCtx('enabled')`) and Nest pipes.

Existing gates (`withFeatureFlag`, etc.) need no changes — their
`(config, handler) => fetchHandler` callable form continues to work
identically, and adapters drive the new path via `gate.run(config)`.

Integration tests run against both Express and Fastify, exercising
admit/reject paths and decorator field-access against the real
`withFeatureFlag` gate.
Verifies the Standard Webhooks signature on Supabase Auth Hook requests
(webhook-id / webhook-timestamp / webhook-signature; HMAC-SHA256 over
`${id}.${timestamp}.${body}`) using Web Crypto — no new dependency — then
injects the decoded payload at ctx.authHook. Rejects forged/unsigned/replayed
requests with 401 before the handler runs. Ships typed payloads for the known
hooks (send-email, send-sms, custom-access-token, mfa, password) with a generic
to narrow ctx.authHook.payload.

Wires ./gates/auth-hook and ./gates/feature-flag as package subpaths in
package.json exports, tsdown.config.ts entries, and jsr.json.
Supabase Auth parses the hook response as JSON; a bare-string body (text/plain)
is rejected with "Invalid JSON response". Clarify that the response shape is the
handler's to choose per hook, and that a body must be JSON.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants