@supabase/server - v1.7.0
    Preparing search index...

    Interface WithSupabaseConfig

    Configuration for withSupabase and createSupabaseContext.

    Controls which auth modes are accepted, environment overrides, and CORS behavior.

    // Require authenticated users, auto-CORS enabled (default)
    const config: WithSupabaseConfig = { auth: 'user' }

    // Accept users or service-to-service calls, custom CORS headers
    const config: WithSupabaseConfig = {
      auth: ['user', 'secret'],
      cors: { 'Access-Control-Allow-Origin': 'https://myapp.com' },
    }

    // No auth required, CORS disabled
    const config: WithSupabaseConfig = { auth: 'none', cors: 'disabled' }
    interface WithSupabaseConfig {
        auth?: AuthConfig;
        allow?: AuthModeWithKey | AuthModeWithKey[];
        audience?: string | string[];
        issuer?: string | string[];
        env?: Partial<SupabaseEnv>;
        cors?:
            | boolean
            | Record<string, string>
            | "default"
            | "disabled"
            | { headers: Record<string, string> };
        supabaseOptions?: SupabaseClientOptions<string>;
        errors?: ErrorResponseConfig;
    }

    Hierarchy (View Summary)

    Index

    Properties

    auth? allow? audience? issuer? env? cors? supabaseOptions? errors?

    Properties

    auth?: AuthConfig

    Auth mode(s) to accept. Modes are tried in order — the first match wins. A mode falls through only when its credential is absent; a present-but-invalid JWT short-circuits the chain with InvalidJwtError (INVALID_JWT).

    "none" matches unconditionally, so it belongs last in a list or on its own — see AuthConfig.

    "user"

    allow?: AuthModeWithKey | AuthModeWithKey[]

    Use WithSupabaseConfig.auth instead. The allow option is kept for backward compatibility and will be removed in a future major release. When both auth and allow are provided, auth takes precedence. It keeps the older, looser element type so code mid-migration still compiles; auth is where the AuthConfig ordering rule is enforced.

    audience?: string | string[]

    Accepted aud claim value(s) for user mode. When set, a token without aud is rejected, and a token whose aud is an array passes when any entry is accepted.

    issuer?: string | string[]

    Accepted iss claim value(s) for user mode. When set, a token without iss is rejected. Supabase Auth issues https://<project-ref>.supabase.co/auth/v1, which fromSupabaseUrl(url) builds from a project URL.

    env?: Partial<SupabaseEnv>

    Override auto-detected environment variables. Useful for testing or when running in environments without standard env var support.

    cors?:
        | boolean
        | Record<string, string>
        | "default"
        | "disabled"
        | { headers: Record<string, string> }

    CORS configuration for the withSupabase wrapper.

    • 'default' — uses @supabase/supabase-js default CORS headers.
    • 'disabled' — disables CORS handling entirely.
    • { headers } — custom CORS headers.

    The boolean (true/false) and bare Record<string, string> forms are deprecated but still accepted for backward compatibility.

    Only applies to the top-level withSupabase wrapper. The adapters (Hono, H3, Elysia, NestJS) handle CORS separately via each framework's own middleware.

    'default'

    supabaseOptions?: SupabaseClientOptions<string>

    Options forwarded to both internal createClient() calls.

    accessToken is stripped, and auth settings (persistSession, autoRefreshToken, detectSessionInUrl) are force-overwritten to server-safe values.

    withSupabase({
      auth: 'user',
      supabaseOptions: { db: { schema: 'api' } },
    }, handler)
    errors?: ErrorResponseConfig

    How much of an error to include in the response body.

    Applies to the responses withSupabase produces. The error object itself is always fully populated, so createSupabaseContext and the framework adapters still see everything.

    ErrorResponseConfig

    Settings

    Member Visibility

    On This Page

    Properties