mirror of
https://github.com/supabase/supabase.git
synced 2026-10-05 09:25:06 +03:00
## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. YES ## What kind of change does this PR introduce? Docs fix, one sentence removed from the `@supabase/middleware` reference intro. ## What is the current behavior? The alpha admonition says the `middleware` option on `withSupabase` in `@supabase/server` is also alpha. That option was removed in `@supabase/server` 1.6.0, where `withSupabase` became a `pipeline` entry, so the sentence describes something that no longer exists. ## What is the new behavior? The admonition keeps the `@supabase/middleware` alpha wording and drops the sentence about the removed option. Both hand-maintained copies of the intro are updated and stay identical: the spec partial that renders the reference site, and the `docs/ref` copy that feeds the markdown build. ## Additional context Same two-file pattern the `@supabase/server` reference uses for its intro and installing partials. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Updated middleware documentation to clarify that only the `@supabase/middleware` package is in alpha. - Removed the alpha-status notice for the `withSupabase` middleware option in `@supabase/server`. - Clarified that `@supabase/middleware` APIs may change between 0.x releases. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
27 lines
1.9 KiB
Plaintext
27 lines
1.9 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.
|
|
|
|
<Admonition type="caution" title="Alpha">
|
|
|
|
`@supabase/middleware` is in alpha. APIs may change between 0.x releases.
|
|
|
|
</Admonition>
|
|
|
|
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.
|