mirror of
https://github.com/supabase/supabase.git
synced 2026-10-08 10:55:06 +03:00
Miranda Limonczenko
63c165311e
Closes DOCS-1318 ## Problem An agent was asked to build an Edge Function returning the order history for whoever is signed in and calling it. Three runs, all correct: each one used the page's `auth: 'user'` pattern and read through the caller-scoped client. The eval scores 7 of 7, including the guide-read check. These are the gaps that showed up around it. | Finding | What the page does now | Why it matters | | --- | --- | --- | | Two clients, no guidance | The first example destructures `supabase` and `supabaseAdmin` together and labels the second "bypasses RLS (service role)" | A reader skimming for the client to use sees two, and one of them is wrong for that section | | No consequence named | "Bypasses RLS" is the strongest phrasing anywhere | A handler querying a shared table through the privileged client without a filter returns every user's rows. The page never said so | | `verify_jwt` as a value to set | Appears six times, five of them as something to change | Switching it off to clear a 401 in development is a reported failure. The page never said the default is the safe one | ## Solution - **Say which client to reach for**, in the section where both are handed over. - **Name the outcome** in a `danger` admonition: a handler that queries a shared table through `ctx.supabaseAdmin` without filtering by the caller's ID returns every user's rows. - **Frame `verify_jwt = true` as the default to leave alone** on user-facing functions, and say what turning it off costs. - **Say every project starts with a secret key named `default`.** **Not asserted here:** the eval is not re-run. It was already at 7 of 7, so there is no headroom to measure an improvement. A candidate new check is proposed on DOCS-1318. ## Preview links | Site | Live | Preview | Search for | | ---- | ---- | ------- | ---------- | | Docs | [/docs/guides/functions/auth](https://supabase.com/docs/guides/functions/auth) | [/docs/guides/functions/auth](https://docs-git-docs-functions-auth-eval-findings-supabase.vercel.app/docs/guides/functions/auth) | returns every user's rows | ## Review instructions 1. Open the live and preview links side-by-side. 2. Read Authenticated user calls on the preview. See a paragraph on choosing between `ctx.supabase` and `ctx.supabaseAdmin`, then a `danger` admonition naming the every-user's-rows outcome. 3. See the same section say to leave `verify_jwt = true` on for user-facing functions. 4. Read the note under Service-to-service calls. See it mention the `default` secret key. ## Checklist Check all before review: - [x] I have read [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) - [x] If I wrote a new docs topic or edited an existing topic, I used the `/write-the-docs` or `/edit-the-docs` skill, which references [WORD_LIST](https://github.com/supabase/supabase/blob/master/apps/docs/WORD_LIST.md) and the docs [CONTRIBUTING](https://github.com/supabase/supabase/blob/master/apps/docs/CONTRIBUTING.md) guide <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Clarified that `secret` and `publishable` authentication modes accept the `default` key, and documented how default, wildcard, and additional keys are handled. * Explained that JWT verification is enabled by default and that disabling it leaves `withSupabase` as the only caller-verification step. * Added guidance that admin queries bypass row-level security and should be scoped to the caller when accessing shared tables. * Clarified that service-to-service authentication with `secret` validates only the `default` key. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
Reference Docs
Supabase Reference Docs
Maintainers
If you are a maintainer of any tools in the Supabase ecosystem, you can use this site to provide documentation for the tools & libraries that you maintain.
DocSpec
We use documentation specifications which can be used to generate human-readable docs.
- OpenAPI: for documenting API endpoints.
- SDKSpec (custom to Supabase): for SDKs and client libraries.
- ConfigSpec (custom to Supabase): for configuration options.
- CLISpec (custom to Supabase): for CLI commands and usage.
The benefit of using custom specifications is that we can generate many other types from a strict schema (eg, HTML and manpages). It also means that we can switch to any documentation system we want. On this site we use Next.js, but on Supabase's official website, we use a custom React site and expose only a subset of the available API for each tool.
Contributing
To contribute to docs, see the style guide for how to write a page, and the developers' guide and contributing guide for repo mechanics. If you write with an AI coding agent, use the /write-the-docs skill to draft and /edit-the-docs to revise an existing page.