mirror of
https://github.com/supabase/supabase.git
synced 2026-10-05 01:15:03 +03:00
Katerina Skroumpelou
2013ebf417
## Problem `@supabase/middleware` ships as 1.0.0. The docs still label the `pipeline` entry form of `withSupabase` alpha, and several snippets import `npm:@supabase/server` and `npm:@supabase/middleware` with no version or with a `^0.5.0` pin. A snippet without a version leaves readers and tools to guess one, and a guessed version fails on deploy. ## Solution - Removes the alpha wording from the middleware reference intro and usage examples, the server frameworks partial, and the Bring your own MCP guide. The `@supabase/server` 1.6.0 floor stays. - Pins every `npm:@supabase/server` and `npm:@supabase/middleware` import in the guides to a major range, `@1`, following the `npm:@supabase/supabase-js@2` convention in Managing dependencies. - Bumps the authenticated-mcp-server example to middleware `^1.0.0` and server `^1.9.0`. ~~Blocked by supabase/middleware#49. The `@1` range resolves once 1.0.0 is on npm.~~ <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated authentication, API key, and MCP examples to use versioned Supabase server and middleware packages. * Clarified that pipeline and nested composition behave the same, and that both require `@supabase/server` 1.6.0 or later. * Removed alpha-status labels from `withSupabase` guidance while retaining the 1.6.0 minimum-version requirement. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
21 lines
1.8 KiB
Plaintext
21 lines
1.8 KiB
Plaintext
---
|
|
id: introduction
|
|
title: Introduction
|
|
---
|
|
|
|
`@supabase/middleware` is a framework-agnostic engine for composing server-side request middleware. You write small units with `defineMiddleware`, compose them with `pipeline`, and run the result as a standard Fetch handler on Node, Deno, Bun, and Cloudflare Workers.
|
|
|
|
Each middleware can guard the request, edit the response, or contribute typed values to a shared context that later middleware and your handler read. TypeScript checks the composition: a middleware that needs a value from an earlier middleware will not compile unless that middleware runs first.
|
|
|
|
This package contains the engine and the framework-neutral middleware: `withCors` and `withFeatureFlag`. Supabase-specific middleware such as `withClaims`, `withSupabaseClient`, `withSupabaseAdminClient`, `withPostgresClient`, and `withPostgresAdminClient` ships in [`@supabase/server`](/docs/reference/server/introduction).
|
|
|
|
### Trust model
|
|
|
|
A middleware in your pipeline runs with the same access as your own handler code. It sees the full request, everything earlier middleware put on the context, and every response on the way out. Nothing sandboxes it. Only compose middleware you trust as much as your own code.
|
|
|
|
Ordering is your permission boundary. A middleware can only read context values that earlier entries contributed, so place third-party middleware as early as possible and sensitive contributions as late as possible.
|
|
|
|
### Environment access
|
|
|
|
Middleware reads configuration through `getEnv` instead of `process.env`. On Node, Deno, and Bun, `getEnv` reads the process environment. Cloudflare Workers pass env bindings per request instead of exposing a global environment; the pipeline seeds each request's bindings, and `getEnv` reads the ones for the current request.
|