mirror of
https://github.com/supabase/supabase.git
synced 2026-10-06 18:05:11 +03:00
19d7233580
## 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? Feature — a new UI Library block. Stacked on #49573 (already in main) Fixes AI-1064 ## What is the new behavior? Adds `headless-app-tanstack`: customers sign in, authorize an MCP client, and use the product through agent tool calls. It composes the existing Password-Based Auth, OAuth Consent, and MCP Server blocks. - `/agents` provides a copyable connection prompt, lists OAuth authorizations, and lets customers revoke access. - The shared MCP runtime exposes `whoami` plus example task CRUD tools. Tools use the caller's Supabase client, with database grants and RLS enforcing ownership. - A root-level `supabase/` directory supplies local Auth/OAuth configuration, a declarative tasks schema, and Edge Function files, including `.env.example`. - Docs cover local setup, signing keys, migrations, environment configuration, deployment, and extending the tools. `/example/headless-app` previews the sign-in, consent, connect, and connected states. Shared block fixes make a fresh install work: - Explicit public URL resolution fixes OAuth discovery in local Edge Runtime when middleware runtime detection fails. Both external OAuth access tokens and ordinary authenticated app session tokens remain supported; embedded agents do not need an additional consent flow. - Registry targets keep backend files outside `src/`, and generated consumer routes omit source-only TypeScript suppressions. - Signup respects `auth.email.enable_confirmations`; sign-in/signup preserve the return destination. Missing consent IDs retain the existing error state without serializing `null` into the URL. ## How to test Use the UI Library on **staging** and follow the block pages' instructions. 1. Open the **Headless App** block page for TanStack Start. Install it into a fresh app and follow the setup instructions through connecting an MCP client. 2. Sign up, open `/agents`, and use the connection prompt to authorize a client. Call `whoami`, then create, list, update, and delete a task. 3. Confirm the client appears on `/agents`. Revoke access and verify it disappears and token refresh fails. An existing access token can continue working until it expires. 4. Follow the **MCP Server** block page's embedded-agent instructions using an authenticated app session. Confirm tools work without another OAuth consent flow and `whoami` returns `client_id: null`. 5. With a second user, confirm each user can only access their own tasks. Check that signup behaves correctly for the configured email-confirmation setting. 6. Check the Headless App preview states and run the installed app's typecheck and production build. ## Validation performed Fresh local installation and browser/SDK verification passed: 26 live MCP/Data API checks, 10 Deno tests, and 7 connection-page component tests. Also passed UI Library typecheck, targeted lint, registry/Markdown builds, and fresh consumer typecheck/production build. Both OAuth and ordinary app session authentication were exercised. Hosted deployment and consuming the confirmation-email link were not tested. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **New Features** - Added a TanStack Headless App example with sign-in, OAuth consent, MCP connection, and connected-agent screens. - Added task management tools for listing, creating, updating, and deleting tasks through MCP. - Added connected-agent management, including server URL and prompt copying, refresh, and access revocation. - Added a new Headless App registry block and documentation. - **Bug Fixes** - Preserved intended destinations through sign-up, email confirmation, and protected-route login redirects. - Improved OAuth discovery URL handling across forwarded-host deployments. - **Documentation** - Updated setup, environment, deployment, and Supabase CLI guidance for headless apps and MCP servers. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Cursor Agent <cursoragent@cursor.com> Co-authored-by: Saxon Fletcher <SaxonF@users.noreply.github.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> Co-authored-by: repro <repro@local> Co-authored-by: Raúl Barroso <code@raulb.dev>
73 lines
3.2 KiB
Plaintext
73 lines
3.2 KiB
Plaintext
---
|
|
title: OAuth Consent
|
|
description: OAuth 2.1 consent block for TanStack Start
|
|
---
|
|
|
|
<BlockPreview name="oauth-consent" />
|
|
|
|
## Installation
|
|
|
|
<BlockItem
|
|
name="oauth-consent-tanstack"
|
|
description="OAuth 2.1 consent screen and the /oauth/consent route"
|
|
/>
|
|
|
|
## Folder structure
|
|
|
|
This block includes the [Supabase client](/library/docs/tanstack/client). If you already have one installed, you can skip overwriting it.
|
|
|
|
<RegistryBlock itemName="oauth-consent-tanstack" />
|
|
|
|
## Usage
|
|
|
|
This block installs an OAuth 2.1 consent route at `/oauth/consent`. It is designed for an app that already has authentication: it does not install sign-in, sign-up, or callback routes.
|
|
|
|
When the visitor has no session, the consent screen redirects to `/login` and preserves the original consent URL in the `next` query parameter. Update the `signInPath` prop in `routes/oauth/consent.tsx` if your sign-in route is different.
|
|
|
|
After sign-in, your login page must send the visitor back to the path in `next`; otherwise the OAuth flow stops at your login screen. The password-based auth and social auth blocks follow `next` automatically. For a custom login page, validate that `next` is a relative path before redirecting to it:
|
|
|
|
```ts
|
|
// After sign-in succeeds:
|
|
const next = new URLSearchParams(window.location.search).get('next')
|
|
if (next?.startsWith('/') && !next.startsWith('//')) {
|
|
// `next` may point outside the typed route tree, so use a full navigation.
|
|
window.location.assign(next)
|
|
}
|
|
```
|
|
|
|
Set `VITE_PRODUCT_NAME` in `.env.local` to replace the `Your product` placeholder
|
|
in the consent header. The [Headless App](/library/docs/tanstack/headless-app) uses
|
|
the same value for its agents page. For a custom value in code, change the
|
|
`productName` prop in `routes/oauth/consent.tsx`.
|
|
|
|
### Getting started
|
|
|
|
After installing the block, you'll have the following environment variables in your `.env.local` file:
|
|
|
|
```env
|
|
VITE_SUPABASE_URL=
|
|
VITE_SUPABASE_PUBLISHABLE_KEY=
|
|
```
|
|
|
|
- If you're using supabase.com, you can find these values in the [Connect modal](https://supabase.com/dashboard/project/_?showConnect=true&connectTab=frameworks&framework=react&using=vite&with=supabasejs) under App Frameworks or in your project's [API settings](https://supabase.com/dashboard/project/_/settings/api).
|
|
- If you're using a local instance of Supabase, you can find these values by running `supabase start` or `supabase status` (if you already have it running).
|
|
|
|
### Configure the OAuth server
|
|
|
|
Enable the OAuth server in the Supabase Dashboard under **Authentication** > **OAuth Server**, then set its authorization URL path to `/oauth/consent`. For local development, set the following in `supabase/config.toml`:
|
|
|
|
```toml
|
|
[auth.oauth_server]
|
|
enabled = true
|
|
authorization_url_path = "/oauth/consent"
|
|
```
|
|
|
|
Recent CLI versions already write an `[auth.oauth_server]` section with `enabled = false`. Edit that section rather than adding a second one, which fails with `table oauth_server already exists`.
|
|
|
|
The route expects the `authorization_id` query parameter that Supabase Auth supplies during the authorization flow.
|
|
|
|
## Further reading
|
|
|
|
- [OAuth Server](https://supabase.com/docs/guides/auth/oauth-server)
|
|
- [Supabase Auth](https://supabase.com/docs/guides/auth)
|