mirror of
https://github.com/supabase/supabase.git
synced 2026-10-05 09:25:06 +03:00
Miranda Limonczenko
a4106b01f5
## Problem These findings came from a technical audit and verification of the claims in the doc. I found two accuracy problems: - **The guide said `getClaims()` is safe to trust** because it "validates the JWT signature against the project's published public keys every time". That only describes projects on asymmetric signing keys. With a symmetric secret it calls the Auth server instead, which the page's own partial already said. The advanced guide then read as a flat contradiction: `getUser()` was "the only way" to know a session is valid. The real distinction is revocation, not verification. - **Running the Express sample verbatim doesn't work.** In the docs sandbox, it printed `SUPABASE_URL = undefined`, so `createServerClient` received undefined for both the URL and the key. The env var tab installed dotenv twice, once inline and once through the package manager tabs, and its "And initialize it" lead-in was followed by the second install rather than any initialization. The route sample then required dotenv without calling `config()`. ## Solution - Say what `getClaims()` verifies against in each signing key mode. - Reframe the advanced guide's `getUser()` answer around session revocation, so the two pages stop contradicting each other. - Switch the advanced guide's two middleware snippets from `getUser()` to `getClaims()`, matching the guide. - Rename its `Next.js middleware` heading and CloudFront bullet, which the proxy rename missed. - Load dotenv on the first line of the Express entry point, and drop the duplicate install. - Tag both Express fences `js`. They are CommonJS, not TypeScript. - Update the stale "middleware refreshing user sessions" comment in the rendered Next.js `server.ts` sample. ## Manual testing 1. Open the [SSR client guide](https://docs-git-docs-ssr-client-accuracy-supabase.vercel.app/docs/guides/auth/server-side/creating-a-client) on the deploy preview, then the Express tab. dotenv is installed once, followed by `require('dotenv').config()`. 2. Open the [advanced guide](https://docs-git-docs-ssr-client-accuracy-supabase.vercel.app/docs/guides/auth/server-side/advanced-guide). The Next.js heading reads `Next.js proxy` and both snippets call `getClaims()`. Part of DOCS-1313. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Clarified the difference between token validation and detecting revoked server-side sessions. - Updated Next.js guidance and examples to use “proxy” terminology. - Refined CloudFront caching guidance for authenticated routes. - Improved Express setup instructions, including dotenv loading and JavaScript examples. - Expanded explanations of signing-key verification. - Updated Astro and Nuxt examples to forward cache headers correctly. - Updated session-refresh guidance in the Next.js example to reference the proxy. <!-- 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 developers' guide and contributing guide.