mirror of
https://github.com/supabase/supabase.git
synced 2026-10-06 01:45:10 +03:00
codex/fix-tanstack-e2e
3
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
3f205627e0 |
feat(library): redesign the site around the block catalog (#50372)
## 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 — the visual redesign itself. Part 5 of 6 in a stack that splits the library redesign into reviewable pieces. The four PRs beneath it carry the build, content and Markdown work; what's left here is layout, navigation and styling. ## What is the current behavior? The library is laid out like a documentation site: a sidebar tree of framework folders, a homepage that lists links, and a guide page that opens with prose. That shape suits reference material, but the library's job is to help someone find a block and install it — and the sidebar is the only way to discover one. ## What is the new behavior? The homepage is the catalog itself — blocks grouped by what they do (authentication, database, storage, realtime, messaging, AI, foundations) rather than by framework, each with a preview of what it renders, filterable by category. Navigation moves into a site header whose Explore menu opens the same categories, so the catalog is reachable from any page and the per-page sidebar tree is gone. A guide opens with what the reader came for: the block's name, the install command, and a preview pane with tabs — the running component and its files — before any prose. The file tree that used to sit mid-page under "Folder structure" is one of those tabs. Every guide also offers a copy of the agent prompt that points at its Markdown. Getting-started pages get the same treatment: the quickstart is now a framework-tabbed walkthrough rather than a wall of setup links. ## Additional context `BlockOverviewTabs` renders Preview and Files here. #50369, stacked on top of this one, adds the third "What's added" tab — it is the only part of the redesign that depends on the new resource analyzer, which is why it sits above this PR rather than below it. Also removes what the redesign orphaned: the table-of-contents component and its `remark` / `mdast-util-toc` dependencies, and the sidebar nav and command-item configuration the new header replaced. The block source changes are typography only — auth card titles move from `text-2xl` to `font-medium text-lg tracking-normal` — which is what regenerates the auth registry artifacts. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added a redesigned Supabase Library catalog with categorized blocks, framework-aware navigation, previews, file views, and installation actions. * Added framework-specific quickstart guides for Next.js, React, Vue, Nuxt, React Router, and TanStack Start. * Added copy-to-clipboard prompts, “Open in v0” actions, starter templates, and richer visual previews. * **Improvements** * Updated documentation layouts, FAQ content, typography, navigation, accessibility, and responsive behavior. * Improved mobile navigation, framework selection, and standardized block installation guidance. * Refined authentication and social-login block presentation with more consistent heading styles. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> Co-authored-by: Danny White <3104761+dnywh@users.noreply.github.com> |
||
|
|
19d7233580 |
feat(ui-library): add headless app block for TanStack Start (#49579)
## 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> |
||
|
Saxon Fletcher
|
a045804e73 |
OAuth Consent Block (#48917)
<img width="1510" height="860" alt="image" src="https://github.com/user-attachments/assets/36a748b7-bdeb-4685-8bb1-da911711874b" /> Introduces a new OAuth consent block in preparation for offering more MCP focused blocks that require authentication and consent. The general approach for this is to decouple consent block from authentication block but provide guidance on how to use both. The alternative is to add auth as a dependency to consent but apps may already have their own authentication UI / flows. The block is also positioned as a general OAuth Consent vs MCP Consent as it can be put to use for other use cases outside of MCP on projects who want to make use of the OAuth 2.1 Server offering. A couple of changes outside of the block itself were required: - Updated the Auth blocks to allow for a `next` param to redirect users to after signing in - Updated middleware so next param is correctly passed through to sign in ## How to test Requires Docker and a Supabase CLI recent enough to support `[auth.oauth_server]` (verified on 2.109.0 / GoTrue v2.192.0). ### 1. Local Supabase with the OAuth server enabled In your `supabase/config.toml`, edit the existing `[auth.oauth_server]` section — `supabase init` already writes one, and adding a second fails with `table oauth_server already exists`: ```toml [auth.oauth_server] enabled = true authorization_url_path = "/oauth/consent" allow_dynamic_registration = true ``` Set `site_url` to wherever your test app runs (e.g. `http://localhost:3100`), then `supabase start`. Grab the API URL and publishable key from `supabase status`. ### 2. A consumer app with the blocks installed The consent block ships no login route by design, so pair it with an auth block: ```bash npx create-next-app@latest consent-test --ts --tailwind --app --yes ``` ```bash cd consent-test && npx shadcn@latest init -d -y && npx shadcn@latest add https://supabase.com/library/r/password-based-auth-nextjs.json https://supabase.com/library/r/oauth-consent-nextjs.json ``` To test this branch before it deploys, run `pnpm --filter ui-library dev` and use `http://localhost:3004/library/r/...` instead. If you changed anything under `registry/default/blocks/oauth-consent/**`, run `pnpm --filter ui-library build:registry` first — shadcn fetches the generated `public/r/*.json`, not the source. Put `NEXT_PUBLIC_SUPABASE_URL` and `NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY` in `.env.local` and start the app on the port you set as `site_url`. ### 3. Register an OAuth client and start a real authorization request ```bash curl -s -X POST http://127.0.0.1:54321/auth/v1/oauth/clients/register -H "Content-Type: application/json" -d '{"client_name":"Test Client","redirect_uris":["http://localhost:3100/callback"],"grant_types":["authorization_code"],"response_types":["code"],"scope":"openid profile email"}' ``` Then open the authorize URL in a browser (not curl — you need the redirect chain and cookies): ``` http://127.0.0.1:54321/auth/v1/oauth/authorize?client_id=<id>&response_type=code&redirect_uri=http://localhost:3100/callback&scope=openid+profile+email&state=xyz&code_challenge=<challenge>&code_challenge_method=S256 ``` Auth mints the `authorization_id` and redirects to `<site_url>/oauth/consent?authorization_id=…`. An MCP client pointed at your app is an even better driver, since that's the real consumer shape. ### 4. Cases to walk | Case | Expected | | --- | --- | | Signed out, hit the authorize URL | Lands on `/auth/login?next=%2Foauth%2Fconsent%3Fauthorization_id%3D…`; after login, returns to the consent screen | | Consent screen | Shows client name, redirect URI, signed-in email, and requested scopes from `getAuthorizationDetails` | | Allow access | Redirects to `redirect_uri` with `code` and your original `state`; the code exchanges at `/oauth/token` for a real access token | | Deny | Redirects with `error=access_denied` and your `state` | | Re-run the same authorize URL after approving | Skips the screen, straight to callback with a new code | | Visit `/oauth/consent` with no `authorization_id` | "This page needs an authorization_id" | | Stale or bogus `authorization_id` | Error shown, buttons still usable | | Double-click Allow | Exactly one `POST /oauth/authorizations/<id>/consent` | Test the react, react-router, or tanstack variant the same way if you're touching them — the hook is duplicated per framework, so a fix in one doesn't carry. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added an OAuth 2.1 consent experience with client details, requested scopes, redirect URI, and approve/deny actions. * Added OAuth consent examples and registry blocks for Next.js, React, React Router, and TanStack Start. * Added OAuth documentation, navigation, and framework support across the UI library. * **Bug Fixes** * Login flows now safely preserve valid same-origin redirect destinations while rejecting unsafe URLs. * OAuth routes can handle consent flows before authentication and redirect safely to sign-in. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |