From 24be387cdbc3d4eba5ab20aa7185485f790cafcd Mon Sep 17 00:00:00 2001 From: Danny White <3104761+dnywh@users.noreply.github.com> Date: Fri, 4 Sep 2026 09:10:25 +1000 Subject: [PATCH 1/9] docs: use sign in terminology across guides and style guides (#49877) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ## What kind of change does this PR introduce? Docs update. Aligns documentation and style guides with the **Sign in / Sign out / Sign up** platform standard. Closes DOCS-1328. Related to [#49874](https://github.com/supabase/supabase/pull/49874). ## What is the current behavior? Docs style guides prefer _login_ / _log in_. Guide prose uses mixed login and sign in wording. ## What is the new behavior? - [WORD_LIST.md](apps/docs/WORD_LIST.md) and [copywriting.mdx](apps/design-system/content/docs/copywriting.mdx) document the sign in standard - Design-system auth examples updated - Guide prose and API reference spec descriptions updated ### Terminology **Standard:** Use _sign in_, _sign out_, and _sign up_ as verbs. Use _sign-in_, _sign-out_, and _sign-up_ as nouns and adjectives. Match Studio UI labels (**Sign in**, **Sign out**, **Sign up**). **Preserved intentionally:** | Category | Keep as-is | Example | | -------- | ---------- | ------- | | Feature name | social login | `/social-login`, `features.mdx` heading, OAuth provider section | | URL slugs | `login` in paths | `/phone-login`, `/login-flows`, `choosing-login-flow` | | CLI | `supabase login` / `supabase logout` | Reference ids `supabase-login` / `supabase-logout`; executable commands unchanged | | SDK methods | `logout()` | Kotlin/Swift method names in API reference titles and examples | | Third-party UI | Provider product labels | Facebook Login, Kakao Login, portal **Login** buttons | | Postgres | Database terminology | login privileges, login credentials, login via role | | Audit/logging | Log prose | "Generates the following **log** in the Postgres Logs" | | Code and routes | Paths and filenames | `app/login/`, `Login.tsx`, `demos/android-login` | | External URLs | Third-party login pages | `dash.cloudflare.com/login`, `console.neon.tech/login`, `vercel.com/login` | | API identifiers | Event and field names | Audit actions `login`/`logout`, `should_logout_user` | ## To test - Run `pnpm lint:mdx` in `apps/docs` - Spot-check `features.mdx`, `social-login.mdx`, and a provider guide (e.g. Facebook, Kakao) ## Summary by CodeRabbit * **Documentation** * Standardized authentication terminology across guides, reference material, CLI documentation, and copywriting guidance using “sign in,” “sign out,” and “sign up.” * Updated authentication instructions, headings, link text, examples, and SSO guidance for clearer, more consistent wording. * Corrected related grammar, spelling, hyphenation, and documentation links while preserving established product names and implementation commands. * **Style** * Refined code examples with consistent import ordering and spacing. * **Examples** * Updated authentication button and menu labels to “Sign in” and “Sign out.” --- .../content/docs/copywriting.mdx | 4 + .../default/example/button-as-child.tsx | 2 +- .../default/example/button-with-icon.tsx | 2 +- .../default/example/dropdown-menu-demo.tsx | 2 +- apps/docs/WORD_LIST.md | 17 ++- apps/docs/content/guides/ai-tools/mcp.mdx | 4 +- .../api/rest/generating-python-types.mdx | 2 +- .../guides/api/rest/generating-types.mdx | 8 +- .../guides/api/using-custom-schemas.mdx | 1 + .../docs/content/guides/auth/architecture.mdx | 2 +- apps/docs/content/guides/auth/audit-logs.mdx | 10 +- .../content/guides/auth/auth-anonymous.mdx | 2 +- .../guides/auth/auth-email-passwordless.mdx | 16 +-- .../auth-hooks/custom-access-token-hook.mdx | 8 +- .../auth-hooks/password-verification-hook.mdx | 12 +- .../guides/auth/auth-identity-linking.mdx | 28 ++--- apps/docs/content/guides/auth/auth-mfa.mdx | 22 ++-- .../content/guides/auth/auth-mfa/phone.mdx | 14 +-- .../content/guides/auth/auth-mfa/totp.mdx | 12 +- apps/docs/content/guides/auth/auth-smtp.mdx | 6 +- .../auth/enterprise-sso/auth-sso-saml.mdx | 6 +- .../guides/auth/general-configuration.mdx | 4 +- .../auth/oauth-server/getting-started.mdx | 4 +- .../guides/auth/oauth-server/oauth-flows.mdx | 4 +- .../content/guides/auth/password-security.mdx | 2 +- apps/docs/content/guides/auth/phone-login.mdx | 16 +-- .../guides/auth/quickstarts/react-native.mdx | 8 +- .../content/guides/auth/quickstarts/react.mdx | 4 +- .../with-expo-react-native-social-auth.mdx | 24 ++-- apps/docs/content/guides/auth/sessions.mdx | 2 +- .../docs/content/guides/auth/social-login.mdx | 12 +- .../guides/auth/social-login/auth-apple.mdx | 2 +- .../guides/auth/social-login/auth-azure.mdx | 6 +- .../auth/social-login/auth-bitbucket.mdx | 10 +- .../guides/auth/social-login/auth-discord.mdx | 12 +- .../auth/social-login/auth-facebook.mdx | 22 ++-- .../guides/auth/social-login/auth-figma.mdx | 10 +- .../guides/auth/social-login/auth-github.mdx | 8 +- .../guides/auth/social-login/auth-gitlab.mdx | 10 +- .../guides/auth/social-login/auth-google.mdx | 4 +- .../guides/auth/social-login/auth-kakao.mdx | 8 +- .../auth/social-login/auth-keycloak.mdx | 8 +- .../auth/social-login/auth-linkedin.mdx | 12 +- .../guides/auth/social-login/auth-notion.mdx | 12 +- .../guides/auth/social-login/auth-slack.mdx | 10 +- .../guides/auth/social-login/auth-spotify.mdx | 12 +- .../guides/auth/social-login/auth-twitch.mdx | 12 +- .../guides/auth/social-login/auth-twitter.mdx | 10 +- .../guides/auth/social-login/auth-workos.mdx | 8 +- .../guides/auth/social-login/auth-zoom.mdx | 12 +- .../content/guides/auth/third-party/auth0.mdx | 2 +- apps/docs/content/guides/auth/users.mdx | 2 +- .../database/custom-postgres-config.mdx | 2 +- .../guides/database/extensions/pgvector.mdx | 1 + .../guides/database/postgres/roles.mdx | 4 +- .../database/postgres/row-level-security.mdx | 4 +- .../content/guides/database/secure-data.mdx | 2 +- .../guides/deployment/database-migrations.mdx | 4 +- .../shared-responsibility-model.mdx | 2 +- .../guides/functions/auth-legacy-jwt.mdx | 2 +- .../content/guides/functions/dependencies.mdx | 1 + apps/docs/content/guides/functions/deploy.mdx | 2 +- .../guides/functions/examples/discord-bot.mdx | 2 +- .../functions/examples/upstash-redis.mdx | 2 +- .../guides/functions/kysely-postgres.mdx | 2 +- .../content/guides/functions/quickstart.mdx | 2 +- .../guides/getting-started/features.mdx | 22 ++-- .../getting-started/quickstarts/laravel.mdx | 2 +- .../getting-started/quickstarts/nextjs.mdx | 2 +- .../getting-started/quickstarts/refine.mdx | 6 +- .../getting-started/quickstarts/tanstack.mdx | 2 +- .../tutorials/with-angular.mdx | 4 +- .../tutorials/with-expo-react-native.mdx | 4 +- .../tutorials/with-flutter.mdx | 4 +- .../tutorials/with-ionic-angular.mdx | 4 +- .../tutorials/with-ionic-react.mdx | 4 +- .../tutorials/with-ionic-vue.mdx | 4 +- .../getting-started/tutorials/with-kotlin.mdx | 2 +- .../getting-started/tutorials/with-nextjs.mdx | 14 +-- .../getting-started/tutorials/with-nuxt-3.mdx | 2 +- .../getting-started/tutorials/with-react.mdx | 4 +- .../tutorials/with-redwoodjs.mdx | 6 +- .../getting-started/tutorials/with-refine.mdx | 10 +- .../tutorials/with-solidjs.mdx | 4 +- .../getting-started/tutorials/with-svelte.mdx | 4 +- .../tutorials/with-sveltekit.mdx | 4 +- .../getting-started/tutorials/with-swift.mdx | 4 +- .../getting-started/tutorials/with-vue-3.mdx | 2 +- .../guides/integrations/stripe-projects.mdx | 2 +- .../local-development/database-migrations.mdx | 2 +- .../declarative-database-schemas.mdx | 4 +- .../monitoring-and-debugging/debugging.mdx | 2 +- .../guides/platform/custom-domains.mdx | 6 +- .../manage-your-usage/logs-ingest.mdx | 2 +- .../monthly-active-users-sso.mdx | 2 +- .../monthly-active-users-third-party.mdx | 6 +- .../monthly-active-users.mdx | 2 +- .../migrating-to-supabase/amazon-rds.mdx | 2 +- .../platform/migrating-to-supabase/auth0.mdx | 14 +-- .../migrating-to-supabase/firebase-auth.mdx | 4 +- .../firebase-storage.mdx | 2 +- .../migrating-to-supabase/firestore-data.mdx | 2 +- .../platform/migrating-to-supabase/heroku.mdx | 2 +- .../platform/migrating-to-supabase/mssql.mdx | 2 +- .../platform/migrating-to-supabase/mysql.mdx | 2 +- .../platform/migrating-to-supabase/neon.mdx | 2 +- .../platform/migrating-to-supabase/render.mdx | 2 +- .../migrating-to-supabase/vercel-postgres.mdx | 2 +- .../backup-restore.mdx | 2 +- .../platform/multi-factor-authentication.mdx | 6 +- .../guides/platform/network-restrictions.mdx | 2 +- .../content/guides/platform/privatelink.mdx | 2 +- .../guides/platform/ssl-enforcement.mdx | 2 +- apps/docs/content/guides/platform/sso.mdx | 38 +++---- .../content/guides/platform/sso/azure.mdx | 6 +- .../platform/sso/choosing-login-flow.mdx | 22 ++-- .../sso/enterprise-mcp-authentication.mdx | 4 +- .../content/guides/platform/sso/gsuite.mdx | 8 +- .../guides/platform/sso/login-flows.mdx | 34 +++--- .../platform/sso/multiple-providers.mdx | 10 +- .../docs/content/guides/platform/sso/okta.mdx | 8 +- .../platform/sso/testing-best-practices.mdx | 104 +++++++++--------- ...consuming-messages-with-edge-functions.mdx | 1 + .../guides/security/platform-security.mdx | 2 +- .../content/guides/self-hosting/docker.mdx | 6 +- .../guides/self-hosting/self-hosted-oauth.mdx | 56 +++++----- .../self-hosting/self-hosted-phone-mfa.mdx | 12 +- .../self-hosting/self-hosted-saml-sso.mdx | 16 +-- .../storage/management/copy-move-objects.mdx | 4 + .../storage/management/delete-objects.mdx | 1 + .../guides/storage/serving/downloads.mdx | 3 + apps/docs/spec/cli_v1_commands--old.yaml | 4 +- apps/docs/spec/cli_v1_commands.yaml | 10 +- apps/docs/spec/cli_v1_config.yaml | 4 +- .../dart/v2/partials/introduction.mdx | 2 +- .../javascript/v2/partials/introduction.mdx | 2 +- apps/docs/spec/supabase_csharp_v0.yml | 12 +- apps/docs/spec/supabase_csharp_v1.yml | 14 +-- apps/docs/spec/supabase_dart_v1.yml | 14 +-- apps/docs/spec/supabase_dart_v2.yml | 22 ++-- apps/docs/spec/supabase_js_v1.yml | 18 +-- apps/docs/spec/supabase_kt_v1.yml | 28 ++--- apps/docs/spec/supabase_kt_v2.yml | 26 ++--- apps/docs/spec/supabase_kt_v3.yml | 26 ++--- apps/docs/spec/supabase_py_v2.yml | 20 ++-- apps/docs/spec/supabase_swift_v1.yml | 12 +- apps/docs/spec/supabase_swift_v2.yml | 6 +- 147 files changed, 630 insertions(+), 601 deletions(-) diff --git a/apps/design-system/content/docs/copywriting.mdx b/apps/design-system/content/docs/copywriting.mdx index 4709faa48feb7..2e8fe0b71c854 100644 --- a/apps/design-system/content/docs/copywriting.mdx +++ b/apps/design-system/content/docs/copywriting.mdx @@ -226,6 +226,10 @@ Use a fragment with no trailing period, and prefer declarative over instructiona | "Handle errors" | "View and resolve errors" | | "Work with data" | "Query and update data" | +## Authentication terminology + +Use **Sign in**, **Sign out**, and **Sign up** for button and menu labels. Keep `login`, `logout`, and `logOut` in code, routes, URL slugs, and CLI commands only when they match existing implementation names. + ## Capitalization - **Sentence case** for all UI text (buttons, labels, section headings) diff --git a/apps/design-system/registry/default/example/button-as-child.tsx b/apps/design-system/registry/default/example/button-as-child.tsx index 4a7cdfcdb07df..8d8909cdb50b6 100644 --- a/apps/design-system/registry/default/example/button-as-child.tsx +++ b/apps/design-system/registry/default/example/button-as-child.tsx @@ -4,7 +4,7 @@ import { Button } from 'ui' export default function ButtonAsChild() { return ( ) } diff --git a/apps/design-system/registry/default/example/button-with-icon.tsx b/apps/design-system/registry/default/example/button-with-icon.tsx index 70d24d18310b4..54ebaab7968e4 100644 --- a/apps/design-system/registry/default/example/button-with-icon.tsx +++ b/apps/design-system/registry/default/example/button-with-icon.tsx @@ -2,5 +2,5 @@ import { Mail } from 'lucide-react' import { Button } from 'ui' export default function ButtonWithIcon() { - return + return } diff --git a/apps/design-system/registry/default/example/dropdown-menu-demo.tsx b/apps/design-system/registry/default/example/dropdown-menu-demo.tsx index 40ca46ba1d3dd..c67490d0ad6ec 100644 --- a/apps/design-system/registry/default/example/dropdown-menu-demo.tsx +++ b/apps/design-system/registry/default/example/dropdown-menu-demo.tsx @@ -112,7 +112,7 @@ export default function DropdownMenuDemo() { - Log out + Sign out ⇧⌘Q diff --git a/apps/docs/WORD_LIST.md b/apps/docs/WORD_LIST.md index 8fb46f2b22d81..e3ee4af18cc16 100644 --- a/apps/docs/WORD_LIST.md +++ b/apps/docs/WORD_LIST.md @@ -473,11 +473,8 @@ Write _lifecycle_, not _life cycle_ or _life-cycle_. ### login and log in -Use _login_ as a noun or adjective and _log in_ as a verb. Follow the terminology -in the product UI when it uses _sign in_. - -- Recommended: Open the login page, and then log in. -- Not recommended: Login to the Dashboard. +Don't use _login_ or _log in_ in prose. Use _sign in_. See +[sign in and sign-in](#sign-in-and-sign-in). ## M @@ -655,6 +652,16 @@ Use _setup_ as a noun or adjective and _set up_ as a verb. - Recommended: Complete the setup to set up authentication. - Not recommended: Setup authentication. +### sign in and sign-in + +Use _sign in_, _sign out_, and _sign up_ as verbs. Use the hyphenated forms +_sign-in_, _sign-out_, and _sign-up_ as nouns or adjectives. Match the product UI +labels **Sign in**, **Sign out**, and **Sign up**. + +Keep _login_, _log in_, _logout_, _log out_, and `logOut` when quoting +third-party UI or when they are part of code, routes, URL slugs, CLI commands, or +established feature names such as _social login_. + ### singular they Use _they_, _them_, and _their_ as gender-neutral singular pronouns. Don't use diff --git a/apps/docs/content/guides/ai-tools/mcp.mdx b/apps/docs/content/guides/ai-tools/mcp.mdx index 0cfcc6e6af1b5..314cbb241e857 100644 --- a/apps/docs/content/guides/ai-tools/mcp.mdx +++ b/apps/docs/content/guides/ai-tools/mcp.mdx @@ -24,9 +24,9 @@ Choose your Supabase platform, project, and MCP client and follow the installati ### Next steps -Your MCP client automatically redirects you to log in to Supabase during setup. This opens a browser window where you can log in to your Supabase account and grant access to the MCP client. Be sure to choose the organization that contains the project you wish to work with. +Your MCP client automatically redirects you to sign in to Supabase during setup. This opens a browser window where you can sign in to your Supabase account and grant access to the MCP client. Be sure to choose the organization that contains the project you wish to work with. -After you log in, check that the MCP server is connected. For instance, in Cursor, navigate to **Settings > Cursor Settings > Tools & MCP**. Depending on the client, you may need to restart it to connect and detect all tools after authorization. +After you sign in, check that the MCP server is connected. For instance, in Cursor, navigate to **Settings > Cursor Settings > Tools & MCP**. Depending on the client, you may need to restart it to connect and detect all tools after authorization. To verify the client has access to the MCP server tools, try asking it to query your project or database using natural language. For example: "What tables are there in the database? Use MCP tools." diff --git a/apps/docs/content/guides/api/rest/generating-python-types.mdx b/apps/docs/content/guides/api/rest/generating-python-types.mdx index 8e3b42acbcb76..1ba0492e84630 100644 --- a/apps/docs/content/guides/api/rest/generating-python-types.mdx +++ b/apps/docs/content/guides/api/rest/generating-python-types.mdx @@ -17,7 +17,7 @@ You can [install the CLI](https://www.npmjs.com/package/supabase) via npm or oth npm i supabase --save-dev ``` -Login with your Personal Access Token: +Sign in with your Personal Access Token: ```bash npx supabase login diff --git a/apps/docs/content/guides/api/rest/generating-types.mdx b/apps/docs/content/guides/api/rest/generating-types.mdx index 64762769bc451..72462efef7443 100644 --- a/apps/docs/content/guides/api/rest/generating-types.mdx +++ b/apps/docs/content/guides/api/rest/generating-types.mdx @@ -22,7 +22,7 @@ You can [install the CLI](https://www.npmjs.com/package/supabase) via npm or oth npm i supabase@">=1.8.1" --save-dev ``` -Login with your Personal Access Token: +Sign in with your Personal Access Token: ```bash npx supabase login @@ -99,6 +99,7 @@ You can supply the type definitions to `supabase-js` like so: ```ts ./index.tsx import { createClient } from '@supabase/supabase-js' + import { Database } from './database.types' const supabase = createClient( @@ -123,7 +124,9 @@ export interface Database { ```ts ./database.types.ts import { MergeDeep } from 'type-fest' + import { Database as DatabaseGenerated } from './database-generated.types' + export { Json } from './database-generated.types' // Override the type for a specific column in a view: @@ -160,6 +163,7 @@ You can extend your generated database types to include custom JSON schemas usin ```ts ./database.types.ts import { MergeDeep } from 'type-fest' + import { Database as DatabaseGenerated } from './database-generated.types' // Define your custom JSON type @@ -280,7 +284,7 @@ create table cities ( We can get the nested `CountriesWithCities` type like this: ```ts -import { QueryResult, QueryData, QueryError } from '@supabase/supabase-js' +import { QueryData, QueryError, QueryResult } from '@supabase/supabase-js' const countriesWithCitiesQuery = supabase.from('countries').select(` id, diff --git a/apps/docs/content/guides/api/using-custom-schemas.mdx b/apps/docs/content/guides/api/using-custom-schemas.mdx index dc788a700250d..842f94d5013ae 100644 --- a/apps/docs/content/guides/api/using-custom-schemas.mdx +++ b/apps/docs/content/guides/api/using-custom-schemas.mdx @@ -45,6 +45,7 @@ Now you can access these schemas from data APIs: ```js // Initialize the JS client import { createClient } from '@supabase/supabase-js' + const supabase = createClient(SUPABASE_URL, SUPABASE_PUBLISHABLE_KEY, { db: { schema: 'myschema' }, }) diff --git a/apps/docs/content/guides/auth/architecture.mdx b/apps/docs/content/guides/auth/architecture.mdx index 3665526c40c12..053c76df6ae70 100644 --- a/apps/docs/content/guides/auth/architecture.mdx +++ b/apps/docs/content/guides/auth/architecture.mdx @@ -55,7 +55,7 @@ The Auth service is responsible for: - Validating, issuing, and refreshing JWTs - Serving as the intermediary between your app and Auth information in the database -- Communicating with external providers for Social Login and SSO +- Communicating with external providers for social login and SSO ## Postgres diff --git a/apps/docs/content/guides/auth/audit-logs.mdx b/apps/docs/content/guides/auth/audit-logs.mdx index 9d74ea36edb68..9a57fa2220059 100644 --- a/apps/docs/content/guides/auth/audit-logs.mdx +++ b/apps/docs/content/guides/auth/audit-logs.mdx @@ -11,10 +11,10 @@ Auth audit logs provide comprehensive tracking of authentication events in your Supabase auth audit logs automatically capture all authentication events including: -- User signups and logins +- User sign-ups and sign-ins - Password changes and resets - Email verification events -- Token refresh and logout events +- Token refresh and sign-out events ## Storage options @@ -53,8 +53,8 @@ Audit logs contain detailed information about each authentication event: | Action | Description | | ------------------------------- | --------------------------------------- | -| `login` | User login attempt | -| `logout` | User logout | +| `login` | User sign-in attempt | +| `logout` | User sign-out | | `invite_accepted` | Team invitation accepted | | `user_signedup` | New user registration | | `user_invited` | User invitation sent | @@ -75,7 +75,7 @@ Audit logs contain detailed information about each authentication event: | `factor_deleted` | MFA factor deleted | | `recovery_codes_deleted` | MFA recovery codes deleted | | `factor_updated` | MFA factor settings updated | -| `mfa_code_login` | Login with MFA code | +| `mfa_code_login` | Sign in with MFA code | | `identity_unlinked` | An identity unlinked from account | ## Limitations diff --git a/apps/docs/content/guides/auth/auth-anonymous.mdx b/apps/docs/content/guides/auth/auth-anonymous.mdx index d3d764d45f52a..5e00867dd860c 100644 --- a/apps/docs/content/guides/auth/auth-anonymous.mdx +++ b/apps/docs/content/guides/auth/auth-anonymous.mdx @@ -342,7 +342,7 @@ Be aware that a single 'restrictive' RLS policy alone will fail unless combined ## Resolving identity conflicts -Depending on your application requirements, data conflicts can arise when an anonymous user is converted to a permanent user. For example, in the context of an e-commerce application, an anonymous user would be allowed to add items to the shopping cart without signing up / signing in. When they decide to sign-in to an existing account, you will need to decide how you want to resolve data conflicts in the shopping cart: +Depending on your application requirements, data conflicts can arise when an anonymous user is converted to a permanent user. For example, in the context of an e-commerce application, an anonymous user would be allowed to add items to the shopping cart without signing up / signing in. When they decide to sign in to an existing account, you will need to decide how you want to resolve data conflicts in the shopping cart: 1. Overwrite the items in the cart with those in the existing account 2. Overwrite the items in the cart with those from the anonymous user diff --git a/apps/docs/content/guides/auth/auth-email-passwordless.mdx b/apps/docs/content/guides/auth/auth-email-passwordless.mdx index 97c8c16089920..73c5f0bc67b2c 100644 --- a/apps/docs/content/guides/auth/auth-email-passwordless.mdx +++ b/apps/docs/content/guides/auth/auth-email-passwordless.mdx @@ -1,24 +1,24 @@ --- -title: 'Passwordless email logins' -subtitle: 'Email logins using Magic Links or One-Time Passwords (OTPs)' +title: 'Passwordless email sign-in' +subtitle: 'Email sign-in using Magic Links or One-Time Passwords (OTPs)' --- -Supabase Auth provides several passwordless login methods. Passwordless logins allow users to sign in without a password, by clicking a confirmation link or entering a verification code. +Supabase Auth provides several passwordless sign-in methods. Passwordless sign-in allows users to sign in without a password, by clicking a confirmation link or entering a verification code. -Passwordless login can: +Passwordless sign-in can: - Improve the user experience by not requiring users to create and remember a password - Increase security by reducing the risk of password-related security breaches - Reduce support burden of dealing with password resets and other password-related flows -Supabase Auth offers two passwordless login methods that use the user's email address: +Supabase Auth offers two passwordless sign-in methods that use the user's email address: - [Magic Link](#with-magic-link) - [OTP](#with-otp) ## With Magic Link -Magic Links are a form of passwordless login where users click on a link sent to their email address to log in to their accounts. Magic Links only work with email addresses and are one-time use only. +Magic Links are a form of passwordless sign-in where users click on a link sent to their email address to sign in to their accounts. Magic Links only work with email addresses and are one-time use only. ### Enabling Magic Link @@ -177,7 +177,7 @@ const { error } = await supabase.auth.verifyOtp({ ## With OTP -Email one-time passwords (OTP) are a form of passwordless login where users key in a six digit code sent to their email address to log in to their accounts. +Email one-time passwords (OTP) are a form of passwordless sign-in where users key in a six-digit code sent to their email address to sign in to their accounts. ### Enabling email OTP @@ -387,7 +387,7 @@ var session = await supabase.Auth.VerifyOTP("email@example.com", "123456", Email -If successful, the user is now logged in, and you receive a valid session that looks like: +If successful, the user is now signed in, and you receive a valid session that looks like: ```json { diff --git a/apps/docs/content/guides/auth/auth-hooks/custom-access-token-hook.mdx b/apps/docs/content/guides/auth/auth-hooks/custom-access-token-hook.mdx index aeb34c9c64ec7..6d6b2b44d2d28 100644 --- a/apps/docs/content/guides/auth/auth-hooks/custom-access-token-hook.mdx +++ b/apps/docs/content/guides/auth/auth-hooks/custom-access-token-hook.mdx @@ -326,7 +326,7 @@ revoke all -You can restrict access to internal applications with a hook. For example, you can require that employees log in via [SAML Single Sign On (SSO)](/docs/guides/auth/enterprise-sso/auth-sso-saml). You can exempt select employees from the policy via an allowlist. +You can restrict access to internal applications with a hook. For example, you can require that employees sign in via [SAML Single Sign On (SSO)](/docs/guides/auth/enterprise-sso/auth-sso-saml). You can exempt select employees from the policy via an allowlist. ```sql create or replace function public.restrict_application_access(event jsonb) @@ -383,9 +383,9 @@ revoke execute Your company wishes to add assign permissions via the role claim on the `app_metadata` field. Add the role claim to the token via a Hook. ```javascript -import { Webhook } from 'https://esm.sh/standardwebhooks@1.0.0' import { readAll } from 'https://deno.land/std/io/read_all.ts' import * as base64 from 'https://denopkg.com/chiefbiiko/base64/mod.ts' +import { Webhook } from 'https://esm.sh/standardwebhooks@1.0.0' Deno.serve(async (req) => { const payload = await req.text() @@ -426,12 +426,12 @@ Deno.serve(async (req) => { -You can restrict access to internal applications with a hook. For example, you can require that employees log in via [SAML Single Sign On (SSO)](/docs/guides/auth/enterprise-sso/auth-sso-saml). You can exempt select employees from the policy via an allowlist. +You can restrict access to internal applications with a hook. For example, you can require that employees sign in via [SAML Single Sign On (SSO)](/docs/guides/auth/enterprise-sso/auth-sso-saml). You can exempt select employees from the policy via an allowlist. ```javascript -import { Webhook } from 'https://esm.sh/standardwebhooks@1.0.0' import { readAll } from 'https://deno.land/std/io/read_all.ts' import * as base64 from 'https://denopkg.com/chiefbiiko/base64/mod.ts' +import { Webhook } from 'https://esm.sh/standardwebhooks@1.0.0' Deno.serve(async (req) => { const payload = await req.text() diff --git a/apps/docs/content/guides/auth/auth-hooks/password-verification-hook.mdx b/apps/docs/content/guides/auth/auth-hooks/password-verification-hook.mdx index 003b453f30ae9..bb941179bad81 100644 --- a/apps/docs/content/guides/auth/auth-hooks/password-verification-hook.mdx +++ b/apps/docs/content/guides/auth/auth-hooks/password-verification-hook.mdx @@ -3,7 +3,7 @@ id: 'password-verification-hook' title: 'Password Verification Hook' --- -Your company wishes to increase security beyond the requirements of the default password implementation in order to fulfill security or compliance requirements. You plan to track the status of a password sign-in attempt and take action via an email or a restriction on logins where necessary. +Your company wishes to increase security beyond the requirements of the default password implementation in order to fulfill security or compliance requirements. You plan to track the status of a password sign-in attempt and take action via an email or a restriction on sign-ins where necessary. As this hook runs on unauthenticated requests, malicious users can abuse the hook by calling it multiple times. Pay extra care when using the hook as you can unintentionally block legitimate users from accessing your application. @@ -57,11 +57,11 @@ Check if a password is valid prior to taking any additional action to ensure the Return these only if your hook processed the input without errors. -| Field | Type | Description | -| -------------------- | --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `decision` | `string` | The decision on whether to allow authentication to move forward. Use `reject` to deny the verification attempt and log the user out of all active sessions. Use `continue` to use the default Supabase Auth behavior. | -| `message` | `string` | The message to show the user if the decision was `reject`. | -| `should_logout_user` | `boolean` | Whether to log out the user if a `reject` decision is issued. Has no effect when a `continue` decision is issued. | +| Field | Type | Description | +| -------------------- | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `decision` | `string` | The decision on whether to allow authentication to move forward. Use `reject` to deny the verification attempt and sign out the user of all active sessions. Use `continue` to use the default Supabase Auth behavior. | +| `message` | `string` | The message to show the user if the decision was `reject`. | +| `should_logout_user` | `boolean` | Whether to sign out the user if a `reject` decision is issued. Has no effect when a `continue` decision is issued. | ```json { diff --git a/apps/docs/content/guides/auth/auth-identity-linking.mdx b/apps/docs/content/guides/auth/auth-identity-linking.mdx index abc0bc9dd0fa3..ad8dc478e8370 100644 --- a/apps/docs/content/guides/auth/auth-identity-linking.mdx +++ b/apps/docs/content/guides/auth/auth-identity-linking.mdx @@ -20,7 +20,7 @@ Users that signed up with [SAML SSO](/docs/guides/auth/enterprise-sso/auth-sso-s ### Automatic linking -Supabase Auth automatically links identities with the same email address to a single user. This helps to improve the user experience when multiple OAuth login options are presented since the user does not need to remember which OAuth account they used to sign up with. When a new user signs in with OAuth, Supabase Auth will attempt to look for an existing user that uses the same email address. If a match is found, the new identity is linked to the user. +Supabase Auth automatically links identities with the same email address to a single user. This helps to improve the user experience when multiple OAuth sign-in options are presented since the user does not need to remember which OAuth account they used to sign up with. When a new user signs in with OAuth, Supabase Auth will attempt to look for an existing user that uses the same email address. If a match is found, the new identity is linked to the user. In order for automatic linking to correctly identify the user for linking, Supabase Auth needs to ensure that all user emails are unique. It would also be an insecure practice to automatically link an identity to a user with an unverified email address since that could lead to pre-account takeover attacks. To prevent this from happening, when a new identity can be linked to an existing user, Supabase Auth will remove any other unconfirmed identities linked to an existing user. @@ -35,7 +35,7 @@ In order for automatic linking to correctly identify the user for linking, Supab > -Supabase Auth allows a user to initiate identity linking with a different email address when they are logged in. To link an OAuth identity to the user, call [`linkIdentity()`](/docs/reference/javascript/auth-linkidentity): +Supabase Auth allows a user to initiate identity linking with a different email address when they are signed in. To link an OAuth identity to the user, call [`linkIdentity()`](/docs/reference/javascript/auth-linkidentity): ```js import { createClient } from '@supabase/supabase-js' @@ -50,7 +50,7 @@ const { data, error } = await supabase.auth.linkIdentity({ provider: 'google' }) <$Show if="sdk:dart"> -Supabase Auth allows a user to initiate identity linking with a different email address when they are logged in. To link an OAuth identity to the user, call [`linkIdentity()`](/docs/reference/dart/auth-linkidentity): +Supabase Auth allows a user to initiate identity linking with a different email address when they are signed in. To link an OAuth identity to the user, call [`linkIdentity()`](/docs/reference/dart/auth-linkidentity): ```dart await supabase.auth.linkIdentity(OAuthProvider.google); @@ -61,7 +61,7 @@ await supabase.auth.linkIdentity(OAuthProvider.google); <$Show if="sdk:swift"> -Supabase Auth allows a user to initiate identity linking with a different email address when they are logged in. To link an OAuth identity to the user, call [`linkIdentity()`](/docs/reference/swift/auth-linkidentity): +Supabase Auth allows a user to initiate identity linking with a different email address when they are signed in. To link an OAuth identity to the user, call [`linkIdentity()`](/docs/reference/swift/auth-linkidentity): ```swift try await supabase.auth.linkIdentity(provider: .google) @@ -72,7 +72,7 @@ try await supabase.auth.linkIdentity(provider: .google) <$Show if="sdk:kotlin"> -Supabase Auth allows a user to initiate identity linking with a different email address when they are logged in. To link an OAuth identity to the user, call [`linkIdentity()`](/docs/reference/kotlin/auth-linkidentity): +Supabase Auth allows a user to initiate identity linking with a different email address when they are signed in. To link an OAuth identity to the user, call [`linkIdentity()`](/docs/reference/kotlin/auth-linkidentity): ```kotlin supabase.auth.linkIdentity(Google) @@ -83,7 +83,7 @@ supabase.auth.linkIdentity(Google) <$Show if="sdk:python"> -Supabase Auth allows a user to initiate identity linking with a different email address when they are logged in. To link an OAuth identity to the user, call [`link_identity()`](/docs/reference/python/auth-linkidentity): +Supabase Auth allows a user to initiate identity linking with a different email address when they are signed in. To link an OAuth identity to the user, call [`link_identity()`](/docs/reference/python/auth-linkidentity): ```python response = supabase.auth.link_identity({'provider': 'google'}) @@ -94,7 +94,7 @@ response = supabase.auth.link_identity({'provider': 'google'}) <$Show if="sdk:csharp"> -Supabase Auth allows a user to initiate identity linking with a different email address when they are logged in. To link an OAuth identity to the user, call [`LinkIdentity()`](/docs/reference/csharp/link-identity): +Supabase Auth allows a user to initiate identity linking with a different email address when they are signed in. To link an OAuth identity to the user, call [`LinkIdentity()`](/docs/reference/csharp/link-identity): ```c# var state = await supabase.Auth.LinkIdentity(Provider.Google, new SignInOptions { FlowType = OAuthFlowType.PKCE }); @@ -175,7 +175,7 @@ This method supports the same OAuth providers as `signInWithIdToken()`: Google, > -You can use [`getUserIdentities()`](/docs/reference/javascript/auth-getuseridentities) to fetch all the identities linked to a user. Then, call [`unlinkIdentity()`](/docs/reference/javascript/auth-unlinkidentity) to unlink the identity. The user needs to be logged in and have at least 2 linked identities in order to unlink an existing identity. +You can use [`getUserIdentities()`](/docs/reference/javascript/auth-getuseridentities) to fetch all the identities linked to a user. Then, call [`unlinkIdentity()`](/docs/reference/javascript/auth-unlinkidentity) to unlink the identity. The user needs to be signed in and have at least 2 linked identities in order to unlink an existing identity. ```js import { createClient } from '@supabase/supabase-js' @@ -201,7 +201,7 @@ if (!identitiesError) { <$Show if="sdk:dart"> -You can use [`getUserIdentities()`](/docs/reference/dart/auth-getuseridentities) to fetch all the identities linked to a user. Then, call [`unlinkIdentity()`](/docs/reference/dart/auth-unlinkidentity) to unlink the identity. The user needs to be logged in and have at least 2 linked identities in order to unlink an existing identity. +You can use [`getUserIdentities()`](/docs/reference/dart/auth-getuseridentities) to fetch all the identities linked to a user. Then, call [`unlinkIdentity()`](/docs/reference/dart/auth-unlinkidentity) to unlink the identity. The user needs to be signed in and have at least 2 linked identities in order to unlink an existing identity. ```dart // retrieve all identities linked to a user @@ -220,7 +220,7 @@ await supabase.auth.unlinkIdentity(googleIdentity); <$Show if="sdk:swift"> -You can use [`getUserIdentities()`](/docs/reference/swift/auth-getuseridentities) to fetch all the identities linked to a user. Then, call [`unlinkIdentity()`](/docs/reference/swift/auth-unlinkidentity) to unlink the identity. The user needs to be logged in and have at least 2 linked identities in order to unlink an existing identity. +You can use [`getUserIdentities()`](/docs/reference/swift/auth-getuseridentities) to fetch all the identities linked to a user. Then, call [`unlinkIdentity()`](/docs/reference/swift/auth-unlinkidentity) to unlink the identity. The user needs to be signed in and have at least 2 linked identities in order to unlink an existing identity. ```swift // retrieve all identities linked to a user @@ -238,7 +238,7 @@ try await supabase.auth.unlinkIdentity(googleIdentity) <$Show if="sdk:kotlin"> -You can use [`currentIdentitiesOrNull()`](/docs/reference/kotlin/auth-getuseridentities) to get all the identities linked to a user. Then, call [`unlinkIdentity()`](/docs/reference/kotlin/auth-unlinkidentity) to unlink the identity. The user needs to be logged in and have at least 2 linked identities in order to unlink an existing identity. +You can use [`currentIdentitiesOrNull()`](/docs/reference/kotlin/auth-getuseridentities) to get all the identities linked to a user. Then, call [`unlinkIdentity()`](/docs/reference/kotlin/auth-unlinkidentity) to unlink the identity. The user needs to be signed in and have at least 2 linked identities in order to unlink an existing identity. ```kotlin //get all identities linked to a user @@ -256,7 +256,7 @@ supabase.auth.unlinkIdentity(googleIdentity.identityId!!) <$Show if="sdk:python"> -You can use [`get_user_identities()`](/docs/reference/python/auth-getuseridentities) to fetch all the identities linked to a user. Then, call [`unlink_identity()`](/docs/reference/python/auth-unlinkidentity) to unlink the identity. The user needs to be logged in and have at least 2 linked identities in order to unlink an existing identity. +You can use [`get_user_identities()`](/docs/reference/python/auth-getuseridentities) to fetch all the identities linked to a user. Then, call [`unlink_identity()`](/docs/reference/python/auth-unlinkidentity) to unlink the identity. The user needs to be signed in and have at least 2 linked identities in order to unlink an existing identity. ```python # retrieve all identities linked to a user @@ -275,7 +275,7 @@ if google_identity: <$Show if="sdk:csharp"> -Use `CurrentUser.Identities` to get all the identities linked to a user. Then, call [`UnlinkIdentity()`](/docs/reference/csharp/unlink-identity) to unlink the identity. The user needs to be logged in and have at least 2 linked identities in order to unlink an existing identity. +Use `CurrentUser.Identities` to get all the identities linked to a user. Then, call [`UnlinkIdentity()`](/docs/reference/csharp/unlink-identity) to unlink the identity. The user needs to be signed in and have at least 2 linked identities in order to unlink an existing identity. ```c# // get all identities linked to the user @@ -294,7 +294,7 @@ await supabase.Auth.UnlinkIdentity(googleIdentity); ## Frequently asked questions -### How to add email/password login to an OAuth account? +### How to add email/password sign-in to an OAuth account? Call the `updateUser({ password: 'validpassword'})` to add email with password authentication to an account created with an OAuth provider (Google, GitHub, etc.). diff --git a/apps/docs/content/guides/auth/auth-mfa.mdx b/apps/docs/content/guides/auth/auth-mfa.mdx index 1a0c97bdde1f5..d90c6b96fd767 100644 --- a/apps/docs/content/guides/auth/auth-mfa.mdx +++ b/apps/docs/content/guides/auth/auth-mfa.mdx @@ -11,7 +11,7 @@ It is considered a best practice to use MFA for your applications. Users with weak passwords or compromised social login accounts are prone to malicious account takeovers. These can be prevented with MFA because they require the user to provide proof of both of these: - Something they know. - Password, or access to a social-login account. + Password, or access to a social login account. - Something they have. Access to an authenticator app (a.k.a. TOTP) or a mobile phone. @@ -24,7 +24,7 @@ Applications using MFA require two important flows: 1. **Enrollment flow.** This lets users set up and control MFA in your app. 2. **Authentication flow.** - This lets users sign in using any factors after the conventional login step. + This lets users sign in using any factors after the conventional sign-in step. Supabase Auth provides: @@ -41,9 +41,9 @@ Once users have enrolled or signed-in with a factor, Supabase Auth adds addition This information is represented by an [Authenticator Assurance Level](https://pages.nist.gov/800-63-3-Implementation-Resources/63B/AAL/), a standard measure about the assurance of the user's identity Supabase Auth has for that particular session. There are two levels recognized today: 1. **Assurance Level 1: `aal1`** - Means that the user's identity was verified using a conventional login method + Means that the user's identity was verified using a conventional sign-in method such as email+password, magic link, one-time password, phone auth or social - login. + sign-in. 2. **Assurance Level 2: `aal2`** Means that the user's identity was additionally verified using at least one second factor, such as a TOTP code or One-Time Password code. @@ -61,12 +61,12 @@ Adding MFA to your app involves these four steps: 2. **Add unenroll flow.** You need to support a UI through which users can see existing devices and unenroll devices which are no longer relevant. -3. **Add challenge step to login.** - If a user has set-up MFA, your app's login flow needs to present a challenge +3. **Add challenge step to sign in.** + If a user has set-up MFA, your app's sign-in flow needs to present a challenge screen to the user asking them to prove they have access to the additional factor. 4. **Enforce rules for MFA logins.** - Once your users have a way to enroll and log in with MFA, you need to enforce + Once your users have a way to enroll and sign in with MFA, you need to enforce authorization rules across your app: on the frontend, backend, API servers or Row-Level Security policies. @@ -291,7 +291,7 @@ If your application uses the Supabase Database, Storage or Edge Functions, Row L 2. **Retrieve the `aal` claim from the JWT and compare its value according to your needs.** If you've encountered an AAL level that can be increased, ask the user to - continue the login process instead of logging them out. + continue the sign-in process instead of logging them out. 3. **Use the `https://.supabase.co/rest/v1/auth/factors` REST endpoint to identify if the user has enrolled any MFA factors.** Only `verified` factors should be acted upon. @@ -349,7 +349,7 @@ Once you have extracted the most recent entry in the array, you can compare the Currently recognized authentication methods are: -- `oauth` - any OAuth based sign in (social login). +- `oauth` - any OAuth-based sign-in (social login). - `password` - any password based sign in. - `otp` - any one-time password based sign in (email code, SMS code, magic link). @@ -361,8 +361,8 @@ The following additional claims are available when using PKCE flow: - `invite` - any sign in via an invitation. - `magiclink` - any sign in via magic link. Excludes logins resulting from invocation of `signUp`. -- `email/signup` - any login resulting from an email signup. -- `email_change` - any login resulting from a change in email. +- `email/signup` - any sign-in resulting from an email signup. +- `email_change` - any sign-in resulting from a change in email. More authentication methods will be added over time as we increase the number of authentication methods supported by Supabase. diff --git a/apps/docs/content/guides/auth/auth-mfa/phone.mdx b/apps/docs/content/guides/auth/auth-mfa/phone.mdx index 2bf410157f7ea..8e838878353f9 100644 --- a/apps/docs/content/guides/auth/auth-mfa/phone.mdx +++ b/apps/docs/content/guides/auth/auth-mfa/phone.mdx @@ -8,7 +8,7 @@ description: 'Add an additional layer of security with phone (SMS or WhatsApp) m Phone multi-factor authentication involves a shared code generated by Supabase Auth and the end user. The code is delivered via a messaging channel, such as SMS or WhatsApp, and the user uses the code to authenticate to Supabase Auth. -The phone messaging configuration for MFA is shared with [phone auth login](/docs/guides/auth/phone-login). The same provider configuration that is used for phone login is used for MFA. You can also use the [Send SMS Hook](/docs/guides/auth/auth-hooks/send-sms-hook) if you need to use an MFA (Phone) messaging provider different from what is supported natively. +The phone messaging configuration for MFA is shared with [phone auth sign-in](/docs/guides/auth/phone-login). The same provider configuration that is used for phone sign-in is used for MFA. You can also use the [Send SMS Hook](/docs/guides/auth/auth-hooks/send-sms-hook) if you need to use an MFA (Phone) messaging provider different from what is supported natively. Below is a flow chart illustrating how the Enrollment and Verify APIs work in the context of MFA (Phone). @@ -34,14 +34,14 @@ flowchart TD In the **setup flow**, a session already at AAL1 calls the Enroll API followed by the Challenge API, which sends a code to the user over SMS or WhatsApp. The user enters the code, the Verify API checks it, and on success the session is upgraded to AAL2. An incorrect code returns the user to the code-entry step. -In the **login flow**, the user signs in (upgrading the session to AAL1) and the List Factors API is called. If the user has one or more factors, they select their phone factor and enter the code that was sent, following the same Verify path to reach AAL2. If they have no factors enrolled, they are sent through the setup flow first. +In the **sign-in flow**, the user signs in (upgrading the session to AAL1) and the List Factors API is called. If the user has one or more factors, they select their phone factor and enter the code that was sent, following the same Verify path to reach AAL2. If they have no factors enrolled, they are sent through the setup flow first. ### Add enrollment flow An enrollment flow provides a UI for users to set up additional authentication factors. Most applications add the enrollment flow in two places within their app: -1. Right after login or sign up. - This allows users to set up Multi Factor Authentication (MFA) post login or account creation. Where possible, encourage all users to set up MFA. Many applications offer this as an opt-in step in an +1. Right after sign-in or sign up. + This allows users to set up Multi Factor Authentication (MFA) post sign-in or account creation. Where possible, encourage all users to set up MFA. Many applications offer this as an opt-in step in an effort to reduce onboarding friction. 2. From within a settings page. Allows users to set up, disable or modify their MFA settings. @@ -159,9 +159,9 @@ export function EnrollMFA({ } ``` -### Add a challenge step to login +### Add a challenge step to sign in -Once a user has logged in via their first factor (email+password, magic link, one time password, social login etc.) you need to perform a check if any additional factors need to be verified. +Once a user has signed in via their first factor (email+password, magic link, one-time password, social login etc.) you need to perform a check if any additional factors need to be verified. This can be done by using the `supabase.auth.mfa.getAuthenticatorAssuranceLevel()` API. When the user signs in and is redirected back to your app, you should call this method to extract the user's current and next authenticator assurance level (AAL). @@ -178,7 +178,7 @@ Below is a table that explains the combined meaning. #### Example: React -Adding the challenge step to login depends heavily on the architecture of your app. However, a fairly common way to structure React apps is to have a large component (often named `App`) which contains most of the authenticated application logic. +Adding the challenge step to sign in depends heavily on the architecture of your app. However, a fairly common way to structure React apps is to have a large component (often named `App`) which contains most of the authenticated application logic. This example will wrap this component with logic that will show an MFA challenge screen if necessary, before showing the full application. This is illustrated in the `AppWithMFA` example below. diff --git a/apps/docs/content/guides/auth/auth-mfa/totp.mdx b/apps/docs/content/guides/auth/auth-mfa/totp.mdx index 2660dea758a70..53cf98f68b586 100644 --- a/apps/docs/content/guides/auth/auth-mfa/totp.mdx +++ b/apps/docs/content/guides/auth/auth-mfa/totp.mdx @@ -34,7 +34,7 @@ flowchart TD In the **setup flow**, a session already at AAL1 calls the Enroll API, which returns a QR code for the user to scan with their authenticator app. The user enters the generated code, the Challenge and Verify APIs check it, and on success the session is upgraded to AAL2. If the code is incorrect, the user is prompted to enter it again. -In the **login flow**, the user signs in (upgrading the session to AAL1) and the List Factors API is called. If the user has one or more factors, they open their authenticator and enter a code, which follows the same Challenge and Verify path to reach AAL2. If they have no factors enrolled, they are sent through the setup flow first. +In the **sign-in flow**, the user signs in (upgrading the session to AAL1) and the List Factors API is called. If the user has one or more factors, they open their authenticator and enter a code, which follows the same Challenge and Verify path to reach AAL2. If they have no factors enrolled, they are sent through the setup flow first. @@ -46,8 +46,8 @@ In the **login flow**, the user signs in (upgrading the session to AAL1) and the An enrollment flow provides a UI for users to set up additional authentication factors. Most applications add the enrollment flow in two places within their app: -1. Right after login or sign up. - This lets users set up MFA immediately after they log in or create an +1. Right after sign-in or sign up. + This lets users set up MFA immediately after they sign in or create an account. We recommend encouraging all users to set up MFA if that makes sense for your application. Many applications offer this as an opt-in step in an effort to reduce onboarding friction. @@ -169,9 +169,9 @@ export function EnrollMFA({ } ``` -### Add a challenge step to login +### Add a challenge step to sign in -Once a user has logged in via their first factor (email+password, magic link, one time password, social login etc.) you need to perform a check if any additional factors need to be verified. +Once a user has signed in via their first factor (email+password, magic link, one-time password, social login etc.) you need to perform a check if any additional factors need to be verified. This can be done by using the `supabase.auth.mfa.getAuthenticatorAssuranceLevel()` API. When the user signs in and is redirected back to your app, you should call this method to extract the user's current and next authenticator assurance level (AAL). @@ -188,7 +188,7 @@ Below is a table that explains the combined meaning. #### Example: React -Adding the challenge step to login depends heavily on the architecture of your app. However, a fairly common way to structure React apps is to have a large component (often named `App`) which contains most of the authenticated application logic. +Adding the challenge step to sign in depends heavily on the architecture of your app. However, a fairly common way to structure React apps is to have a large component (often named `App`) which contains most of the authenticated application logic. This example will wrap this component with logic that will show an MFA challenge screen if necessary, before showing the full application. This is illustrated in the `AppWithMFA` example below. diff --git a/apps/docs/content/guides/auth/auth-smtp.mdx b/apps/docs/content/guides/auth/auth-smtp.mdx index 7ff2e24882895..75b4e5466011d 100644 --- a/apps/docs/content/guides/auth/auth-smtp.mdx +++ b/apps/docs/content/guides/auth/auth-smtp.mdx @@ -143,7 +143,7 @@ If you are planning on having a large surge of users coming at a specific time, Consider implementing additional protections for such events: - Build a queuing or waitlist system instead of allowing direct sign-up, which will help you control the number of messages being sent from the email sending service. -- Disable email-based sign ups for the event and use social login only. Alternatively you can deprioritize the email-based sign-up flows for the event by hiding them in the UI or making them harder to reach. +- Disable email-based sign-ups for the event and use social login only. Alternatively you can deprioritize the email-based sign-up flows for the event by hiding them in the UI or making them harder to reach. **Use the Send Email Auth Hook for more control.** @@ -161,6 +161,6 @@ If you need more control over the sending process, instead of using a SMTP serve **Increase the duration of user sessions.** -Having short lived [user sessions](/docs/guides/auth/sessions) can be problematic for email sending, as it forces active users to sign-in frequently, increasing the number of messages needed to be sent. Consider increasing the maximum duration of user sessions. If you do see an unnecessary increase in logins without a clear cause, check your frontend application for bugs. +Having short-lived [user sessions](/docs/guides/auth/sessions) can be problematic for email sending, as it forces active users to sign in frequently, increasing the number of messages needed to be sent. Consider increasing the maximum duration of user sessions. If you do see an unnecessary increase in sign-ins without a clear cause, check your frontend application for bugs. -If you are using a [SSR](/docs/guides/auth/server-side) framework on the frontend and are seeing an increased number of user logins without a clear cause, check your set up. Make sure to keep the `@supabase/ssr` package up to date and closely follow the guides we publish. Make sure that the middleware components of your SSR frontend works as intended and matches the guides we've published. Sometimes a misplaced `return` or conditional can cause early session termination. +If you are using a [SSR](/docs/guides/auth/server-side) framework on the frontend and are seeing an increased number of user sign-ins without a clear cause, check your set up. Make sure to keep the `@supabase/ssr` package up to date and closely follow the guides we publish. Make sure that the middleware components of your SSR frontend works as intended and matches the guides we've published. Sometimes a misplaced `return` or conditional can cause early session termination. diff --git a/apps/docs/content/guides/auth/enterprise-sso/auth-sso-saml.mdx b/apps/docs/content/guides/auth/enterprise-sso/auth-sso-saml.mdx index c839c206fee9b..9a4d0ccc22133 100644 --- a/apps/docs/content/guides/auth/enterprise-sso/auth-sso-saml.mdx +++ b/apps/docs/content/guides/auth/enterprise-sso/auth-sso-saml.mdx @@ -79,11 +79,11 @@ Alternatively, you can use the `supabase sso info --project-ref ` User accounts and identities created via SSO differ from regular (email, phone, password, social login...) accounts in these ways: - **No identity linking.** - Each user account verified using an SSO identity provider are not legible for [identity linking](/docs/guides/auth/auth-identity-linking) to existing user accounts for security reasons. That is, if a user `valid.email@supabase.io` had signed up with a password, and then uses their company SSO login with your project, there will be two `valid.email@supabase.io` user accounts in the system. + Each user account verified using an SSO identity provider are not eligible for [identity linking](/docs/guides/auth/auth-identity-linking) to existing user accounts for security reasons. That is, if a user `valid.email@supabase.io` had signed up with a password, and then uses their company SSO sign-in with your project, there will be two `valid.email@supabase.io` user accounts in the system. - **Emails are not necessarily unique.** Given the behavior with no identity linking, email addresses are no longer a unique identifier for a user account. Always use the user's UUID to correctly reference user accounts. - **Sessions may have a maximum duration.** - Depending on the configuration of the identity provider, a login session established with SSO may forcibly log out a user after a certain period of time. + Depending on the configuration of the identity provider, a sign-in session established with SSO may forcibly sign out a user after a certain period of time. ### Row Level Security @@ -94,7 +94,7 @@ Here are some commonly used statements to extract SSO related information from t - `auth.jwt()#>>'{amr,0,method}'` Returns the name of the last method used to verify the identity of this user. With SAML SSO this is `sso/saml`. - `auth.jwt()#>>'{amr,0,provider}'` - Returns the UUID of the SSO identity provider used by the user to sign-in. + Returns the UUID of the SSO identity provider used by the user to sign in. - `auth.jwt()#>>'{user_metadata,iss}'` Returns the identity provider's SAML 2.0 `EntityID` diff --git a/apps/docs/content/guides/auth/general-configuration.mdx b/apps/docs/content/guides/auth/general-configuration.mdx index fcb98df27917b..0bc629faf7b30 100644 --- a/apps/docs/content/guides/auth/general-configuration.mdx +++ b/apps/docs/content/guides/auth/general-configuration.mdx @@ -7,7 +7,7 @@ subtitle: 'General configuration options for Supabase Auth' This section covers the [general configuration options](/dashboard/project/_/auth) for Supabase Auth. If you are looking for another type of configuration, you may be interested in one of the following sections: - [Policies](/dashboard/project/_/database/policies) to manage Row Level Security policies for your tables. -- [Sign In / Providers](/dashboard/project/_/auth/providers) to configure authentication providers and login methods for your users. +- [Sign In / Providers](/dashboard/project/_/auth/providers) to configure authentication providers and sign-in methods for your users. - [Third Party Auth](/dashboard/project/_/auth/third-party) to use third-party authentication (TPA) systems based on JWTs to access your project. - [Sessions](/dashboard/project/_/auth/sessions) to configure settings for user sessions and refresh tokens. - [Rate limits](/dashboard/project/_/auth/rate-limits) to safeguard against bursts of incoming traffic to prevent abuse and maximize stability. @@ -25,7 +25,7 @@ Supabase Auth provides these [general configuration options](/dashboard/project/ - **Allow new users to sign up**: Users will be able to sign up. If this config is disabled, only existing users can sign in. - **Confirm Email**: Users will need to confirm their email address before signing in for the first time. - - Having **Confirm Email** disabled assumes that the user's email does not need to be verified in order to login and implicitly confirms the user's email in the database. + - Having **Confirm Email** disabled assumes that the user's email does not need to be verified in order to sign in and implicitly confirms the user's email in the database. - This option can be found in the email provider under the provider-specific configuration. {/* - If you previously relied on this config to autoconfirm a user's email address, you can switch to use **Allow unverified email sign in** instead. This new option allows the user to sign in with an unverified email which you can keep track of through the user object. It provides more versatility if you require your users to verify their email address in the future since you can structure your RLS policies to check the user's `email_verified` field. */} diff --git a/apps/docs/content/guides/auth/oauth-server/getting-started.mdx b/apps/docs/content/guides/auth/oauth-server/getting-started.mdx index eded448adc3fd..1e5eea02e5572 100644 --- a/apps/docs/content/guides/auth/oauth-server/getting-started.mdx +++ b/apps/docs/content/guides/auth/oauth-server/getting-started.mdx @@ -163,7 +163,7 @@ This is where you build the **frontend** for your authorization flow. When third Your authorization UI should: 1. **Extract authorization_id** - Get the `authorization_id` from the URL query parameters -2. **Authenticate the user** - If not already logged in, redirect to your login page (preserving the authorization_id) +2. **Authenticate the user** - If not already signed in, redirect to your sign-in page (preserving the authorization_id) 3. **Retrieve authorization details** - Use `supabase.auth.oauth.getAuthorizationDetails(authorization_id)` to get client information including requested scopes 4. **Display consent screen** - Show the user what app is requesting access and what scopes/permissions are being requested 5. **Handle user decision** - Call either `approveAuthorization(authorization_id)` or `denyAuthorization(authorization_id)` based on user choice @@ -455,7 +455,7 @@ export function OAuthConsent() { 1. **User navigates to your authorization path** - When a third-party app initiates OAuth, Supabase Auth redirects the user to your configured authorization path (e.g., `https://example.com/oauth/consent?authorization_id=`) 2. **Extract authorization_id** - Your page extracts the `authorization_id` from the URL query parameters -3. **Check authentication** - Your page checks if the user is logged in, redirecting to login if not (preserving the authorization_id) +3. **Check authentication** - Your page checks if the user is signed in, redirecting to sign in if not (preserving the authorization_id) 4. **Retrieve details** - Call `supabase.auth.oauth.getAuthorizationDetails(authorization_id)` to get information about the requesting client 5. **Show consent screen** - Display a UI asking the user to approve or deny access 6. **Handle decision** - When the user clicks approve/deny: diff --git a/apps/docs/content/guides/auth/oauth-server/oauth-flows.mdx b/apps/docs/content/guides/auth/oauth-server/oauth-flows.mdx index 855391dca71f5..f67a2951508e5 100644 --- a/apps/docs/content/guides/auth/oauth-server/oauth-flows.mdx +++ b/apps/docs/content/guides/auth/oauth-server/oauth-flows.mdx @@ -35,7 +35,7 @@ The flow consists of several steps: 1. **Client initiates authorization** - Third-party app redirects user to Supabase Auth's authorize endpoint 2. **Supabase validates and redirects** - Supabase Auth validates OAuth parameters and redirects user to your configured authorization URL -3. **User authenticates and authorizes** - Your frontend checks if user is logged in, shows consent screen, and handles approval/denial +3. **User authenticates and authorizes** - Your frontend checks if user is signed in, shows consent screen, and handles approval/denial 4. **Authorization code issued** - Supabase Auth generates a short-lived authorization code and redirects back to client 5. **Code exchange** - Client exchanges the code for tokens 6. **Access granted** - Client receives access token, refresh token, and ID token @@ -184,7 +184,7 @@ Your frontend application at the authorization path should: 1. **Extract authorization_id** - Get the `authorization_id` from the URL query parameters 2. **Fetch authorization details** - Call `supabase.auth.oauth.getAuthorizationDetails(authorization_id)` to retrieve information about the OAuth client and request parameters -3. **Check user authentication** - Verify if the user is logged in; if not, redirect to your login page (preserving the full authorization path including the `authorization_id`). After successful login, redirect the user back to the authorization path with the same `authorization_id` query parameter +3. **Check user authentication** - Verify if the user is signed in; if not, redirect to your sign-in page (preserving the full authorization path including the `authorization_id`). After successful sign-in, redirect the user back to the authorization path with the same `authorization_id` query parameter 4. **Display consent screen** - Show the user information about the requesting client (name, redirect URI, scopes) 5. **Handle user decision** - When the user approves or denies: - Call `supabase.auth.oauth.approveAuthorization(authorization_id)` to approve diff --git a/apps/docs/content/guides/auth/password-security.mdx b/apps/docs/content/guides/auth/password-security.mdx index 479ff4955a509..428aaeb26f1b8 100644 --- a/apps/docs/content/guides/auth/password-security.mdx +++ b/apps/docs/content/guides/auth/password-security.mdx @@ -16,7 +16,7 @@ This table shows the _minimum_ number of guesses that need to be tried to access In reality though, passwords are not always generated at random. They often contain variations of names, words, dates, and common phrases. Malicious actors can use these properties to guess a password in fewer attempts. -There are hundreds of millions (and growing!) known passwords out there. Malicious actors can use these lists of leaked passwords to automate login attempts (known as credential stuffing) and steal or access sensitive user data. +There are hundreds of millions (and growing!) known passwords out there. Malicious actors can use these lists of leaked passwords to automate sign-in attempts (known as credential stuffing) and steal or access sensitive user data. ## Password strength and leaked password protection diff --git a/apps/docs/content/guides/auth/phone-login.mdx b/apps/docs/content/guides/auth/phone-login.mdx index 7700b558b681a..9b48256870a1e 100644 --- a/apps/docs/content/guides/auth/phone-login.mdx +++ b/apps/docs/content/guides/auth/phone-login.mdx @@ -1,9 +1,9 @@ --- -title: 'Phone Login' -description: 'Learn about logging in to your platform using SMS one-time passwords.' +title: 'Phone sign-in' +description: 'Learn about signing in to your platform using SMS one-time passwords.' --- -Phone Login is a method of authentication that allows users to log in to a website or application without using a password. The user authenticates through a one-time password (OTP) sent via a channel (SMS or WhatsApp). +Phone sign-in is a method of authentication that allows users to sign in to a website or application without using a password. The user authenticates through a one-time password (OTP) sent via a channel (SMS or WhatsApp). @@ -11,9 +11,9 @@ At this time, `WhatsApp` is only supported as a channel for the Twilio and Twili -Users can also log in with their phones using Native Mobile Login with the built-in identity provider. For Native Mobile Login with Android and iOS, see the [Social Login guides](/docs/guides/auth/social-login). +Users can also sign in with their phones using Native Mobile Login with the built-in identity provider. For Native Mobile Login with Android and iOS, see the [social login guides](/docs/guides/auth/social-login). -Phone OTP login can: +Phone OTP sign-in can: - Improve the user experience by not requiring users to create and remember a password - Increase security by reducing the risk of password-related security breaches @@ -21,7 +21,7 @@ Phone OTP login can: <$Partial path="cost_warning.mdx" /> -## Enabling phone login +## Enabling phone sign-in Enable phone authentication on the [Auth Providers page](/dashboard/project/_/auth/providers) for hosted Supabase projects. @@ -229,7 +229,7 @@ curl -X POST 'https://.supabase.co/auth/v1/verify' \ -If successful the user will now be logged in and you should receive a valid session like: +If successful, the user will now be signed in and you should receive a valid session like: ```json { @@ -244,7 +244,7 @@ The access token can be sent in the Authorization header as a Bearer token for a ## Updating a phone number -To update a user's phone number, the user must be logged in. Call [`updateUser()`](/docs/reference/javascript/auth-updateuser) with their phone number: +To update a user's phone number, the user must be signed in. Call [`updateUser()`](/docs/reference/javascript/auth-updateuser) with their phone number: - + Create a helper file `lib/supabase.ts` that exports a Supabase client using your Project URL and key. @@ -90,9 +90,9 @@ hideToc: true - + - Create a React Native component to manage logins and sign ups. The app later uses the [`getClaims`](/docs/reference/javascript/auth-getclaims) method in `App.tsx` to validate the local JWT before showing the signed-in user. + Create a React Native component to manage sign-ins and sign-ups. The app later uses the [`getClaims`](/docs/reference/javascript/auth-getclaims) method in `App.tsx` to validate the local JWT before showing the signed-in user. @@ -111,7 +111,7 @@ hideToc: true - Add the `Auth` component to your `App.tsx` file. If the user is logged in, print the user id to the screen. + Add the `Auth` component to your `App.tsx` file. If the user is signed in, print the user id to the screen. diff --git a/apps/docs/content/guides/auth/quickstarts/react.mdx b/apps/docs/content/guides/auth/quickstarts/react.mdx index f624e8d03eced..a8ac9181ab478 100644 --- a/apps/docs/content/guides/auth/quickstarts/react.mdx +++ b/apps/docs/content/guides/auth/quickstarts/react.mdx @@ -83,7 +83,7 @@ hideToc: true - + <$Partial path="uiLibCta.mdx" /> @@ -121,7 +121,7 @@ hideToc: true - Start the app, go to http://localhost:5173 in a browser, and open the browser console and you should be able to register and log in. + Start the app, go to http://localhost:5173 in a browser, and open the browser console and you should be able to register and sign in. diff --git a/apps/docs/content/guides/auth/quickstarts/with-expo-react-native-social-auth.mdx b/apps/docs/content/guides/auth/quickstarts/with-expo-react-native-social-auth.mdx index 4646c475d567e..dda461e87e2d4 100644 --- a/apps/docs/content/guides/auth/quickstarts/with-expo-react-native-social-auth.mdx +++ b/apps/docs/content/guides/auth/quickstarts/with-expo-react-native-social-auth.mdx @@ -6,7 +6,7 @@ description: 'Learn how to implement social authentication in an app with Expo R This tutorial demonstrates how to build a React Native app with [Expo](https://expo.dev) that implements social authentication. The app showcases a complete authentication flow with protected navigation using: - [Supabase Database](/docs/guides/database/overview) - a Postgres database for storing your user data with [Row Level Security](/docs/guides/auth#row-level-security) to ensure data is protected and users can only access their own information. -- [Supabase Auth](/docs/guides/auth) - enables users to log in through social authentication providers (Apple and Google). +- [Supabase Auth](/docs/guides/auth) - enables users to sign in through social authentication providers (Apple and Google). ![Supabase Social Auth example](/docs/img/supabase-expo-social-auth-login.png) @@ -129,9 +129,9 @@ lines={[[1, -1]]} meta="name=components/splash-screen-controller.tsx" /> -### Create a logout component +### Create a sign-out component -Create a logout button component to handle user sign-out: +Create a sign-out button component to handle user sign-out: <$CodeSample path="/auth/expo-social-auth/components/social-auth-buttons/sign-out-button.tsx" @@ -139,7 +139,7 @@ lines={[[1, -1]]} meta="name=components/social-auth-buttons/sign-out-button.tsx" /> -And add it to the `app/(tabs)/index.tsx` file used to display the user profile data and the logout button: +And add it to the `app/(tabs)/index.tsx` file used to display the user profile data and the sign-out button: <$CodeSample path="/auth/expo-social-auth/app/(tabs)/index.tsx" @@ -147,9 +147,9 @@ lines={[[1, -1]]} meta="name=app/(tabs)/index.tsx" /> -### Create a login screen +### Create a sign-in screen -Next, create a basic login screen component: +Next, create a basic sign-in screen component: <$CodeSample path="/auth/expo-social-auth/app/login.tsx" @@ -177,7 +177,7 @@ npx expo prebuild npx expo start --clear ``` -Verify that the app works as expected. The splash screen displays while fetching the user profile, and the login page appears even when attempting to navigate to the home screen using the `Link` button. +Verify that the app works as expected. The splash screen displays while fetching the user profile, and the sign-in page appears even when attempting to navigate to the home screen using the `Link` button. @@ -194,7 +194,7 @@ If you only need to implement Google authentication, you can skip to the [Google ### Apple authentication -Start by adding the button inside the login screen: +Start by adding the button inside the sign-in screen: <$CodeTabs> @@ -237,7 +237,7 @@ npx expo start --tunnel And add it to the **Redirect URLs** field in [your Supabase dashboard Authentication configuration](/dashboard/project/_/auth/url-configuration). -For more information, follow the [Supabase Login with Apple](/docs/guides/auth/social-login/auth-apple) guide. +For more information, follow the [Supabase Sign in with Apple](/docs/guides/auth/social-login/auth-apple) guide. @@ -343,7 +343,7 @@ For more information, follow the [Supabase Login with Apple](/docs/guides/auth/s npx expo run:ios --no-build-cache --device ``` - You should see the login screen with the Apple authentication button. + You should see the sign-in screen with the Apple authentication button. @@ -466,7 +466,7 @@ For more information, follow the [Supabase Login with Apple](/docs/guides/auth/s ### Google authentication -Start by adding the button to the login screen: +Start by adding the button to the sign-in screen: <$CodeTabs> @@ -543,7 +543,7 @@ EXPO_PUBLIC_GOOGLE_AUTH_WEB_CLIENT_ID="YOUR_GOOGLE_AUTH_WEB_CLIENT_ID" npx expo run:ios && npx expo run:android ``` - You should see the login screen with the Google authentication button. + You should see the sign-in screen with the Google authentication button. ![Supabase Social Auth example](/docs/img/supabase-expo-social-auth-tabs.png) diff --git a/apps/docs/content/guides/auth/sessions.mdx b/apps/docs/content/guides/auth/sessions.mdx index 2a4083b87a2a1..a7e2c6cc13f8c 100644 --- a/apps/docs/content/guides/auth/sessions.mdx +++ b/apps/docs/content/guides/auth/sessions.mdx @@ -115,7 +115,7 @@ It's better for cost optimization and scaling as well, as the authentication sys Most applications rarely need such strong guarantees. Consider adjusting the JWT expiry time to an acceptable value. If this is still necessary, you should try to use this validation logic only for the most sensitive actions within your application. -When a user signs out, the sessions affected by the logout are removed from the database entirely. You can check that the `session_id` claim in the JWT corresponds to a row in the `auth.sessions` table. If such a row does not exist, it means that the user has logged out. +When a user signs out, the sessions affected by the sign-out are removed from the database entirely. You can check that the `session_id` claim in the JWT corresponds to a row in the `auth.sessions` table. If such a row does not exist, it means that the user has signed out. Note that sessions are not proactively terminated when their maximum lifetime (time-box) or inactivity timeout are reached. These sessions are cleaned up progressively 24 hours after reaching that status. This allows you to tweak the values or roll back changes without causing unintended user friction. diff --git a/apps/docs/content/guides/auth/social-login.mdx b/apps/docs/content/guides/auth/social-login.mdx index 6433597e5832e..cdcb87370fe80 100644 --- a/apps/docs/content/guides/auth/social-login.mdx +++ b/apps/docs/content/guides/auth/social-login.mdx @@ -1,20 +1,20 @@ --- -title: 'Social Login' -description: 'Logging in with social accounts' +title: 'Social login' +description: 'Signing in with social accounts' --- -Social Login (OAuth) is an open standard for authentication that allows users to log in to one website or application using their credentials from another website or application. OAuth allows users to grant third-party applications access to their online accounts without sharing their passwords. -OAuth is commonly used for things like logging in to a social media account from a third-party app. It is a secure and convenient way to authenticate users and share information between applications. +Social login (OAuth) is an open standard for authentication that allows users to sign in to one website or application using their credentials from another website or application. OAuth allows users to grant third-party applications access to their online accounts without sharing their passwords. +OAuth is commonly used for things like signing in to a social media account from a third-party app. It is a secure and convenient way to authenticate users and share information between applications. ## Benefits There are several reasons why you might want to add social login to your applications: -- **Improved user experience**: Users can register and log in to your application using their existing social media accounts, which can be faster and more convenient than creating a new account from scratch. This makes it easier for users to access your application, improving their overall experience. +- **Improved user experience**: Users can register and sign in to your application using their existing social media accounts, which can be faster and more convenient than creating a new account from scratch. This makes it easier for users to access your application, improving their overall experience. - **Better user engagement**: You can access additional data and insights about your users, such as their interests, demographics, and social connections. This can help you tailor your content and marketing efforts to better engage with your users and provide a more personalized experience. -- **Increased security**: Social login can improve the security of your application by leveraging the security measures and authentication protocols of the social media platforms that your users are logging in with. This can help protect against unauthorized access and account takeovers. +- **Increased security**: Social login can improve the security of your application by leveraging the security measures and authentication protocols of the social media platforms that your users are signing in with. This can help protect against unauthorized access and account takeovers. ## Set up a social provider with Supabase Auth diff --git a/apps/docs/content/guides/auth/social-login/auth-apple.mdx b/apps/docs/content/guides/auth/social-login/auth-apple.mdx index 78b8d9b0569fa..e98435a57ac12 100644 --- a/apps/docs/content/guides/auth/social-login/auth-apple.mdx +++ b/apps/docs/content/guides/auth/social-login/auth-apple.mdx @@ -1,6 +1,6 @@ --- id: 'auth-apple' -title: 'Login with Apple' +title: 'Sign in with Apple' description: 'Use Sign in with Apple with Supabase' tocVideo: '-tpcZzTdvN0' --- diff --git a/apps/docs/content/guides/auth/social-login/auth-azure.mdx b/apps/docs/content/guides/auth/social-login/auth-azure.mdx index 5d0dd8a3b6033..1c02a4ca4dbd1 100644 --- a/apps/docs/content/guides/auth/social-login/auth-azure.mdx +++ b/apps/docs/content/guides/auth/social-login/auth-azure.mdx @@ -1,6 +1,6 @@ --- id: 'auth-azure' -title: 'Login with Azure (Microsoft)' +title: 'Sign in with Azure (Microsoft)' description: 'Add Azure (Microsoft) OAuth to your Supabase project' --- @@ -18,7 +18,7 @@ Setting up OAuth with Azure consists of four broad steps: ## Access your Azure Developer account - Go to [portal.azure.com](https://portal.azure.com/#home). -- Login and select Microsoft Entra ID under the list of Azure Services. +- Sign in and select Microsoft Entra ID under the list of Azure Services. ## Register an application @@ -140,7 +140,7 @@ If your app is registered as _My organization only_ for the _Supported account t Configure this by storing a value under _Azure Tenant URL_ in the Supabase Auth provider configuration page for Azure that has the following format `https://login.microsoftonline.com/`. -## Add login code to your client app +## Add sign-in code to your client app diff --git a/apps/docs/content/guides/auth/social-login/auth-bitbucket.mdx b/apps/docs/content/guides/auth/social-login/auth-bitbucket.mdx index 45c9dc8a3b299..a482b25519043 100644 --- a/apps/docs/content/guides/auth/social-login/auth-bitbucket.mdx +++ b/apps/docs/content/guides/auth/social-login/auth-bitbucket.mdx @@ -1,6 +1,6 @@ --- id: 'auth-bitbucket' -title: 'Login with Bitbucket' +title: 'Sign in with Bitbucket' description: 'Add Bitbucket OAuth to your Supabase project' --- @@ -8,16 +8,16 @@ To enable Bitbucket Auth for your project, you need to set up a Bitbucket OAuth ## Overview -Setting up Bitbucket logins for your application consists of 3 parts: +Setting up Bitbucket sign-in for your application consists of 3 parts: - Create and configure a Bitbucket OAuth Consumer on [Bitbucket](https://bitbucket.org) - Add your Bitbucket OAuth Consumer keys to your [Supabase Project](/dashboard) -- Add the login code to your [Supabase JS Client App](https://github.com/supabase/supabase-js) +- Add the sign-in code to your [Supabase JS Client App](https://github.com/supabase/supabase-js) ## Access your Bitbucket account - Go to [bitbucket.org](https://bitbucket.org/). -- Click on `Login` at the top right to log in. +- Click on `Login` at the top right to sign in. ![Bitbucket Developer Portal.](/docs/img/guides/auth-bitbucket/bitbucket-portal.png) @@ -44,7 +44,7 @@ Setting up Bitbucket logins for your application consists of 3 parts: <$Partial path="social_provider_settings_supabase.mdx" variables={{ "provider": "BitBucket" }} /> -## Add login code to your client app +## Add sign-in code to your client app -## Set up Facebook login for your Facebook app +## Set up Facebook sign-in for your Facebook app From the `Add Products to your App` screen: @@ -99,7 +99,7 @@ curl -X PATCH "https://api.supabase.com/v1/projects/$PROJECT_REF/config/auth" \ }' ``` -## Add login code to your client app +## Add sign-in code to your client app .supabase.co/auth/v1/callback`. Make sure there are no trailing slashes or typos. -### Login works in development but not production +### Sign-in works in development but not production -If login works locally but fails in production, check: +If sign-in works locally but fails in production, check: - Your production URL is added to **Valid OAuth Redirect URIs** in Facebook - The App ID and Secret in your Supabase dashboard match your Facebook app diff --git a/apps/docs/content/guides/auth/social-login/auth-figma.mdx b/apps/docs/content/guides/auth/social-login/auth-figma.mdx index 1c3a0864d31c4..1148249d6c941 100644 --- a/apps/docs/content/guides/auth/social-login/auth-figma.mdx +++ b/apps/docs/content/guides/auth/social-login/auth-figma.mdx @@ -1,6 +1,6 @@ --- id: 'auth-figma' -title: 'Login with Figma' +title: 'Sign in with Figma' description: 'Add Figma OAuth to your Supabase project' --- @@ -8,16 +8,16 @@ To enable Figma Auth for your project, you need to set up a Figma OAuth applicat ## Overview -Setting up Figma logins for your application consists of 3 parts: +Setting up Figma sign-in for your application consists of 3 parts: - Create and configure a Figma App on the [Figma Developers page](https://www.figma.com/developers/apps). - Add your Figma `client_id` and `client_secret` to your [Supabase Project](https://app.supabase.com). -- Add the login code to your [Supabase JS Client App](https://github.com/supabase/supabase-js). +- Add the sign-in code to your [Supabase JS Client App](https://github.com/supabase/supabase-js). ## Access the Figma Developers page - Go to the [Figma Developers page](https://www.figma.com/developers/apps) -- Log in (if necessary) +- Sign in (if necessary) ## Find your callback URL @@ -44,7 +44,7 @@ Setting up Figma logins for your application consists of 3 parts: <$Partial path="social_provider_settings_supabase.mdx" variables={{ "provider": "Figma" }} /> -## Add login code to your client app +## Add sign-in code to your client app -## Add login code to your client app +## Add sign-in code to your client app -## Add login code to your client app +## Add sign-in code to your client app -Setting up Slack logins for your application consists of 3 parts: +Setting up Slack sign-in for your application consists of 3 parts: - Create and configure a Slack Project and App on the [Slack Developer Dashboard](https://api.slack.com/apps). - Add your Slack `API Key` and `API Secret Key` to your [Supabase Project](/dashboard). -- Add the login code to your [Supabase JS Client App](https://github.com/supabase/supabase-js). +- Add the sign-in code to your [Supabase JS Client App](https://github.com/supabase/supabase-js). ## Access your Slack Developer account - Go to [api.slack.com](https://api.slack.com/apps). -- Click on `Your Apps` at the top right to log in. +- Click on `Your Apps` at the top right to sign in. ![Slack Developer Portal.](/docs/img/guides/auth-slack/slack-portal.png) @@ -80,7 +80,7 @@ curl -X PATCH "https://api.supabase.com/v1/projects/$PROJECT_REF/config/auth" \ }' ``` -## Add login code to your client app +## Add sign-in code to your client app -## Add login code to your client app +## Add sign-in code to your client app -Setting up X / Twitter logins for your application consists of 3 parts: +Setting up X / Twitter sign-in for your application consists of 3 parts: - Create and configure an X Project and App on the [X Developer Dashboard](https://developer.x.com/en/portal/dashboard). - Add your X OAuth 2.0 `Client ID` and `Client Secret` to your [Supabase Project](/dashboard). -- Add the login code to your [Supabase JS Client App](https://github.com/supabase/supabase-js). +- Add the sign-in code to your [Supabase JS Client App](https://github.com/supabase/supabase-js). ## Access your X developer account - Go to [developer.x.com](https://developer.x.com). -- Click on `Sign in` at the top right to log in. +- Click on `Sign in` at the top right to sign in. ## Find your callback URL @@ -77,7 +77,7 @@ curl -X PATCH "https://api.supabase.com/v1/projects/$PROJECT_REF/config/auth" \ }' ``` -## Add login code to your client app +## Add sign-in code to your client app ```typescript -import { createClient } from '@supabase/supabase-js' import { createAuth0Client } from '@auth0/auth0-spa-js' +import { createClient } from '@supabase/supabase-js' const auth0 = await createAuth0Client({ domain: '', diff --git a/apps/docs/content/guides/auth/users.mdx b/apps/docs/content/guides/auth/users.mdx index 0ad2d0c0eff73..60e40de3b4b92 100644 --- a/apps/docs/content/guides/auth/users.mdx +++ b/apps/docs/content/guides/auth/users.mdx @@ -67,7 +67,7 @@ The user object contains the following attributes: | phone_confirmed_at | `string` | The timestamp that the user's phone was confirmed. If null, it means that the user's phone is not confirmed. | | confirmed_at | `string` | The timestamp that either the user's email or phone was confirmed. If null, it means that the user does not have a confirmed email address and phone number. | | last_sign_in_at | `string` | The timestamp that the user last signed in. | -| app_metadata | `object` | The `provider` attribute indicates the first provider that the user used to sign up with. The `providers` attribute indicates the list of providers that the user can use to login with. | +| app_metadata | `object` | The `provider` attribute indicates the first provider that the user used to sign up with. The `providers` attribute indicates the list of providers that the user can use to sign in with. | | user_metadata | `object` | Defaults to the first provider's identity data but can contain additional custom user metadata if specified. Refer to [**User Identity**](/docs/guides/auth/auth-identity-linking#the-user-identity) for more information about the identity object. Don't rely on the order of information in this field. Do not use it in security sensitive context (such as in RLS policies or authorization logic), as this value is editable by the user without any checks. | | identities | `UserIdentity[]` | Contains an object array of identities linked to the user. | | created_at | `string` | The timestamp that the user was created. | diff --git a/apps/docs/content/guides/database/custom-postgres-config.mdx b/apps/docs/content/guides/database/custom-postgres-config.mdx index 0fc8f870b953f..26cb649347d6a 100644 --- a/apps/docs/content/guides/database/custom-postgres-config.mdx +++ b/apps/docs/content/guides/database/custom-postgres-config.mdx @@ -166,7 +166,7 @@ Use the examples below with `supabase postgres-config update --project-ref - - [Login](/docs/reference/cli/supabase-login) to the Supabase CLI using an auto-generated Personal Access Token. + + [Sign in](/docs/reference/cli/supabase-login) to the Supabase CLI using an auto-generated Personal Access Token. diff --git a/apps/docs/content/guides/deployment/shared-responsibility-model.mdx b/apps/docs/content/guides/deployment/shared-responsibility-model.mdx index 41c5d17503931..7808b3b18c986 100644 --- a/apps/docs/content/guides/deployment/shared-responsibility-model.mdx +++ b/apps/docs/content/guides/deployment/shared-responsibility-model.mdx @@ -58,7 +58,7 @@ If you don’t want to implement logic inside your database, that is 100% fine. Supabase offers a lot of opportunities for flexibly integrating with third-party services, such as: -- OAuth and SAML login providers +- OAuth and SAML sign-in providers - SMTP and SMS sending APIs - Calls to external APIs within Postgres functions or triggers - Calls to external APIs within Edge Functions diff --git a/apps/docs/content/guides/functions/auth-legacy-jwt.mdx b/apps/docs/content/guides/functions/auth-legacy-jwt.mdx index 72f19204c05ce..7b9dd624f4c37 100644 --- a/apps/docs/content/guides/functions/auth-legacy-jwt.mdx +++ b/apps/docs/content/guides/functions/auth-legacy-jwt.mdx @@ -47,7 +47,7 @@ This context setting happens in the `Deno.serve()` callback argument, so that th ## Fetching the user -By getting the JWT from the `Authorization` header, you can provide the token to `getUser()` to fetch the user object to obtain metadata for the logged in user. +By getting the JWT from the `Authorization` header, you can provide the token to `getUser()` to fetch the user object to obtain metadata for the signed-in user. ```js Deno.serve(async (req: Request) => { diff --git a/apps/docs/content/guides/functions/dependencies.mdx b/apps/docs/content/guides/functions/dependencies.mdx index 691274669987a..2bb5a5f62d6bf 100644 --- a/apps/docs/content/guides/functions/dependencies.mdx +++ b/apps/docs/content/guides/functions/dependencies.mdx @@ -14,6 +14,7 @@ Supabase Edge Functions support several ways to import dependencies: - Built-in [Node APIs](https://docs.deno.com/runtime/manual/node/compatibility) - Modules published to [JSR](https://jsr.io/) or [deno.land/x](https://deno.land/x) +{/* prettier-ignore */} ```ts // NPM packages (recommended) import { createClient } from 'npm:@supabase/supabase-js@2' diff --git a/apps/docs/content/guides/functions/deploy.mdx b/apps/docs/content/guides/functions/deploy.mdx index 68fdf89629706..eeb9812a16100 100644 --- a/apps/docs/content/guides/functions/deploy.mdx +++ b/apps/docs/content/guides/functions/deploy.mdx @@ -18,7 +18,7 @@ Before getting started, make sure you have the Supabase CLI installed. Check out ## Step 1: Authenticate -Log in to the Supabase CLI if you haven't already: +Sign in to the Supabase CLI if you haven't already: ```bash supabase login diff --git a/apps/docs/content/guides/functions/examples/discord-bot.mdx b/apps/docs/content/guides/functions/examples/discord-bot.mdx index a7ba70a4806f8..75b1eaeca92ee 100644 --- a/apps/docs/content/guides/functions/examples/discord-bot.mdx +++ b/apps/docs/content/guides/functions/examples/discord-bot.mdx @@ -16,7 +16,7 @@ video: 'https://www.youtube.com/v/J24Bvo_m7DM' ## Create an application on Discord Developer portal -1. Go to [https://discord.com/developers/applications](https://discord.com/developers/applications) (login using your discord account if required). +1. Go to [https://discord.com/developers/applications](https://discord.com/developers/applications) (sign in using your discord account if required). 2. Click on **New Application** button available at left side of your profile picture. 3. Name your application and click on **Create**. 4. Go to **Bot** section, click on **Add Bot**, and finally on **Yes, do it!** to confirm. diff --git a/apps/docs/content/guides/functions/examples/upstash-redis.mdx b/apps/docs/content/guides/functions/examples/upstash-redis.mdx index 329607922c289..69324662c1b16 100644 --- a/apps/docs/content/guides/functions/examples/upstash-redis.mdx +++ b/apps/docs/content/guides/functions/examples/upstash-redis.mdx @@ -39,8 +39,8 @@ supabase functions new upstash-redis-counter And add the code to the `index.ts` file: ```ts index.ts -import { Redis } from 'npm:@upstash/redis@^1' import { withSupabase } from 'npm:@supabase/server@^1' +import { Redis } from 'npm:@upstash/redis@^1' console.log(`Function "upstash-redis-counter" up and running!`) diff --git a/apps/docs/content/guides/functions/kysely-postgres.mdx b/apps/docs/content/guides/functions/kysely-postgres.mdx index 9b98eb9b86934..5bca2ba1c46e8 100644 --- a/apps/docs/content/guides/functions/kysely-postgres.mdx +++ b/apps/docs/content/guides/functions/kysely-postgres.mdx @@ -191,6 +191,7 @@ Create an `index.ts` file to execute a query on incoming requests: ```ts index.ts import { Pool } from 'jsr:@db/postgres@^0' +import { withSupabase } from 'npm:@supabase/server@^1' import { Generated, Kysely, @@ -198,7 +199,6 @@ import { PostgresIntrospector, PostgresQueryCompiler, } from 'npm:kysely@^0' -import { withSupabase } from 'npm:@supabase/server@^1' import { PostgresDriver } from './DenoPostgresDriver.ts' diff --git a/apps/docs/content/guides/functions/quickstart.mdx b/apps/docs/content/guides/functions/quickstart.mdx index 9b11d1ec6d666..91eb4ff3e235f 100644 --- a/apps/docs/content/guides/functions/quickstart.mdx +++ b/apps/docs/content/guides/functions/quickstart.mdx @@ -138,7 +138,7 @@ Create one at [database.new](https://database.new/). -First, login to the CLI if you haven't already, and authenticate with Supabase. This opens your browser to authenticate with Supabase; complete the login process in your browser. +First, sign in to the CLI if you haven't already, and authenticate with Supabase. This opens your browser to authenticate with Supabase; complete the sign-in process in your browser. ```bash supabase login diff --git a/apps/docs/content/guides/getting-started/features.mdx b/apps/docs/content/guides/getting-started/features.mdx index b573c41d5d161..cb67510d50142 100644 --- a/apps/docs/content/guides/getting-started/features.mdx +++ b/apps/docs/content/guides/getting-started/features.mdx @@ -74,7 +74,7 @@ Export Supabase logs to third-party providers and external tooling. [Docs](/docs ### Studio Single Sign-On -Login to the Supabase dashboard via SSO. [Docs](/docs/guides/platform/sso). +Sign in to the Supabase dashboard via SSO. [Docs](/docs/guides/platform/sso).
@@ -94,21 +94,21 @@ Synchronize shared state across your users, including online status and typing i ## Auth -### Email login +### Email sign-in -Build email logins for your application or website. [Docs](/docs/guides/auth/passwords). +Build email sign-in for your application or website. [Docs](/docs/guides/auth/passwords). ### Social login -Provide social logins - everything from Apple, to GitHub, to Slack. [Docs](/docs/guides/auth/social-login). +Provide social login - everything from Apple, to GitHub, to Slack. [Docs](/docs/guides/auth/social-login). -### Phone logins +### Phone sign-in -Provide phone logins using a third-party SMS provider. [Docs](/docs/guides/auth/phone-login). +Provide phone sign-in using a third-party SMS provider. [Docs](/docs/guides/auth/phone-login). -### Passwordless login +### Passwordless sign-in -Build passwordless logins via magic links for your application or website. [Docs](/docs/guides/auth/auth-email-passwordless). +Build passwordless sign-in via magic links for your application or website. [Docs](/docs/guides/auth/auth-email-passwordless). ### Authorization via Row Level Security @@ -238,10 +238,10 @@ In addition to the Beta requirements, features in GA are covered by the [uptime | Edge Functions | Regional Invocations | `GA` | ✅ | | Edge Functions | NPM compatibility | `GA` | ✅ | | Auth | | `GA` | ✅ | -| Auth | Email login | `GA` | ✅ | +| Auth | Email sign-in | `GA` | ✅ | | Auth | Social login | `GA` | ✅ | -| Auth | Phone login | `GA` | ✅ | -| Auth | Passwordless login | `GA` | ✅ | +| Auth | Phone sign-in | `GA` | ✅ | +| Auth | Passwordless sign-in | `GA` | ✅ | | Auth | SSO with SAML | `GA` | ✅ | | Auth | Authorization via RLS | `GA` | ✅ | | Auth | CAPTCHA protection | `GA` | ✅ | diff --git a/apps/docs/content/guides/getting-started/quickstarts/laravel.mdx b/apps/docs/content/guides/getting-started/quickstarts/laravel.mdx index cce73dd279023..fcf5b1d129ba5 100644 --- a/apps/docs/content/guides/getting-started/quickstarts/laravel.mdx +++ b/apps/docs/content/guides/getting-started/quickstarts/laravel.mdx @@ -95,7 +95,7 @@ php artisan migrate ## 8. Start the app -Run the development server. Go to http://127.0.0.1:8000 in a browser to see your application. You can also navigate to http://127.0.0.1:8000/register and http://127.0.0.1:8000/login to register and log in users. +Run the development server. Go to http://127.0.0.1:8000 in a browser to see your application. You can also navigate to http://127.0.0.1:8000/register and http://127.0.0.1:8000/login to register and sign in users. ```bash php artisan serve diff --git a/apps/docs/content/guides/getting-started/quickstarts/nextjs.mdx b/apps/docs/content/guides/getting-started/quickstarts/nextjs.mdx index 9ca784530e1f2..57fdfd03fb45c 100644 --- a/apps/docs/content/guides/getting-started/quickstarts/nextjs.mdx +++ b/apps/docs/content/guides/getting-started/quickstarts/nextjs.mdx @@ -39,7 +39,7 @@ NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY= ## 6. Allow public access to the instruments page -The `with-supabase` template redirects unauthenticated visitors to the login page for most routes. The `instruments` table is publicly readable, so update `lib/supabase/proxy.ts` to skip that redirect for `/instruments`. +The `with-supabase` template redirects unauthenticated visitors to the sign-in page for most routes. The `instruments` table is publicly readable, so update `lib/supabase/proxy.ts` to skip that redirect for `/instruments`. Find this `if` statement: diff --git a/apps/docs/content/guides/getting-started/quickstarts/refine.mdx b/apps/docs/content/guides/getting-started/quickstarts/refine.mdx index 1d6921561d508..0d9d6d1f293d1 100644 --- a/apps/docs/content/guides/getting-started/quickstarts/refine.mdx +++ b/apps/docs/content/guides/getting-started/quickstarts/refine.mdx @@ -107,15 +107,15 @@ import { BrowserRouter, Route, Routes } from 'react-router' import './App.css' -import authProvider from './providers/auth' -import { dataProvider } from './providers/data' -import { supabaseClient } from './providers/supabase-client' import { InstrumentsCreate, InstrumentsEdit, InstrumentsList, InstrumentsShow, } from './pages/instruments' +import authProvider from './providers/auth' +import { dataProvider } from './providers/data' +import { supabaseClient } from './providers/supabase-client' function App() { return ( diff --git a/apps/docs/content/guides/getting-started/quickstarts/tanstack.mdx b/apps/docs/content/guides/getting-started/quickstarts/tanstack.mdx index 9d0f220885f99..6cc4ac7a1f9e1 100644 --- a/apps/docs/content/guides/getting-started/quickstarts/tanstack.mdx +++ b/apps/docs/content/guides/getting-started/quickstarts/tanstack.mdx @@ -154,7 +154,7 @@ npm run dev ## Next steps -- Learn how to [protect routes and check sessions](/docs/guides/auth/server-side/creating-a-client?queryGroups=framework&framework=tanstack) with the server client, or drop in a complete [login and sign-up flow](/library/docs/tanstack/password-based-auth) from Supabase Library +- Learn how to [protect routes and check sessions](/docs/guides/auth/server-side/creating-a-client?queryGroups=framework&framework=tanstack) with the server client, or drop in a complete [sign-in and sign-up flow](/library/docs/tanstack/password-based-auth) from Supabase Library - [Insert more data](/docs/guides/database/import-data) into your database - Upload and serve static files using [Storage](/docs/guides/storage) - Explore [drop-in UI components](/ui) for your Supabase app diff --git a/apps/docs/content/guides/getting-started/tutorials/with-angular.mdx b/apps/docs/content/guides/getting-started/tutorials/with-angular.mdx index c65739aed50c6..0f138d95a2e46 100644 --- a/apps/docs/content/guides/getting-started/tutorials/with-angular.mdx +++ b/apps/docs/content/guides/getting-started/tutorials/with-angular.mdx @@ -54,9 +54,9 @@ meta="name=src/app/supabase.service.ts" Optionally, update `src/styles.css` to style the app. You can find the full contents of this file [in the example repository](https://github.com/supabase/supabase/tree/master/examples/user-management/angular-user-management/src/styles.css). -### Set up a login component +### Set up a sign-in component -You need an Angular component to manage logins and sign ups. The component uses [Magic Links](/docs/guides/auth/auth-email-passwordless#with-magic-link), so users can sign in with their email without using passwords. +You need an Angular component to manage sign-ins and sign-ups. The component uses [Magic Links](/docs/guides/auth/auth-email-passwordless#with-magic-link), so users can sign in with their email without using passwords. diff --git a/apps/docs/content/guides/getting-started/tutorials/with-expo-react-native.mdx b/apps/docs/content/guides/getting-started/tutorials/with-expo-react-native.mdx index 64fbbdbc2b116..3f6ef30734477 100644 --- a/apps/docs/content/guides/getting-started/tutorials/with-expo-react-native.mdx +++ b/apps/docs/content/guides/getting-started/tutorials/with-expo-react-native.mdx @@ -166,9 +166,9 @@ lines={[[1, -1]]} meta="name=styles/styles.ts" /> -### Set up a login component +### Set up a sign-in component -Set up a React Native component to manage logins and sign ups. +Set up a React Native component to manage sign-ins and sign-ups. Users should be able to sign in with their email and password. <$CodeSample diff --git a/apps/docs/content/guides/getting-started/tutorials/with-flutter.mdx b/apps/docs/content/guides/getting-started/tutorials/with-flutter.mdx index 19ea149237c05..f5bf9d3944323 100644 --- a/apps/docs/content/guides/getting-started/tutorials/with-flutter.mdx +++ b/apps/docs/content/guides/getting-started/tutorials/with-flutter.mdx @@ -189,9 +189,9 @@ extension ContextExtension on BuildContext { Notice that we have a `showSnackBar` extension method that we will use to show snack bars in the app. You could define this method in a separate file and import it where needed, but for simplicity, we will define it here. -### Set up a login page +### Set up a sign-in page -Create a Flutter widget to manage logins and sign ups. We will use Magic Links, so users can sign in with their email without using passwords. +Create a Flutter widget to manage sign-ins and sign-ups. We will use Magic Links, so users can sign in with their email without using passwords. Notice that this page sets up a listener on the user's auth state using `onAuthStateChange`. A new event will fire when the user comes back to the app by clicking their magic link, which this page can catch and redirect the user accordingly. diff --git a/apps/docs/content/guides/getting-started/tutorials/with-ionic-angular.mdx b/apps/docs/content/guides/getting-started/tutorials/with-ionic-angular.mdx index a1bec2c404b83..0846bcdea8f28 100644 --- a/apps/docs/content/guides/getting-started/tutorials/with-ionic-angular.mdx +++ b/apps/docs/content/guides/getting-started/tutorials/with-ionic-angular.mdx @@ -57,9 +57,9 @@ lines={[[1, -1]]} meta="name=src/app/supabase.service.ts" /> -### Set up a login route +### Set up a sign-in route -Set up a route to manage logins and signups. Use Magic Links so users can sign in with their email without using passwords. +Set up a route to manage sign-ins and sign-ups. Use Magic Links so users can sign in with their email without using passwords. Create a `LoginPage` with the `ionic g page login` Ionic CLI command. <$CodeSample diff --git a/apps/docs/content/guides/getting-started/tutorials/with-ionic-react.mdx b/apps/docs/content/guides/getting-started/tutorials/with-ionic-react.mdx index fac23b6ec1e24..310e4c69efb8b 100644 --- a/apps/docs/content/guides/getting-started/tutorials/with-ionic-react.mdx +++ b/apps/docs/content/guides/getting-started/tutorials/with-ionic-react.mdx @@ -56,9 +56,9 @@ lines={[[1, -1]]} meta="name=src/supabaseClient.ts" /> -### Set up a login route +### Set up a sign-in route -Set up a React component to manage logins and sign ups which uses Magic Links, so users can sign in with their email without using passwords. +Set up a React component to manage sign-ins and sign-ups which uses Magic Links, so users can sign in with their email without using passwords. <$CodeSample path="/user-management/ionic-react-user-management/src/pages/Login.tsx" diff --git a/apps/docs/content/guides/getting-started/tutorials/with-ionic-vue.mdx b/apps/docs/content/guides/getting-started/tutorials/with-ionic-vue.mdx index fcf2908a8266a..a9af115c05af0 100644 --- a/apps/docs/content/guides/getting-started/tutorials/with-ionic-vue.mdx +++ b/apps/docs/content/guides/getting-started/tutorials/with-ionic-vue.mdx @@ -54,9 +54,9 @@ lines={[[1, -1]]} meta="name=src/supabase.ts" /> -### Set up a login route +### Set up a sign-in route -Create a Vue component to manage logins and sign ups that uses Magic Links, so users can sign in with their email without using passwords. +Create a Vue component to manage sign-ins and sign-ups that uses Magic Links, so users can sign in with their email without using passwords. <$CodeSample path="/user-management/ionic-vue-user-management/src/views/Login.vue" diff --git a/apps/docs/content/guides/getting-started/tutorials/with-kotlin.mdx b/apps/docs/content/guides/getting-started/tutorials/with-kotlin.mdx index 877c240120dad..8bbabde0dc531 100644 --- a/apps/docs/content/guides/getting-started/tutorials/with-kotlin.mdx +++ b/apps/docs/content/guides/getting-started/tutorials/with-kotlin.mdx @@ -6,7 +6,7 @@ description: 'Learn how to use Supabase in your Android Kotlin App.' This tutorial demonstrates how to build a basic product management app. The app demonstrates management operations, photo upload, account creation and authentication using: - [Supabase Database](/docs/guides/database/overview) - a Postgres database for storing your user data and [Row Level Security](/docs/guides/auth#row-level-security) so data is protected and users can only access their own information. -- [Supabase Auth](/docs/guides/auth) - users log in through magic links sent to their email (without having to set up a password). +- [Supabase Auth](/docs/guides/auth) - users sign in through magic links sent to their email (without having to set up a password). - [Supabase Storage](/docs/guides/storage) - users can upload a profile photo. ![manage-product-cover](/docs/img/guides/kotlin/manage-product-cover.png) diff --git a/apps/docs/content/guides/getting-started/tutorials/with-nextjs.mdx b/apps/docs/content/guides/getting-started/tutorials/with-nextjs.mdx index 9fd1f84564e12..8060eeec0a685 100644 --- a/apps/docs/content/guides/getting-started/tutorials/with-nextjs.mdx +++ b/apps/docs/content/guides/getting-started/tutorials/with-nextjs.mdx @@ -126,11 +126,11 @@ meta="name=lib/supabase/proxy.ts" -### Set up a login page +### Set up a sign-in page -#### Login and signup form +#### Sign-in and sign-up form -To add login/signup page for your application, create a new folder named `login`, containing a `page.tsx` file with the following code for a login/signup form: +To add sign-in/sign-up page for your application, create a new folder named `login`, containing a `page.tsx` file with the following code for a sign-in/sign-up form: <$CodeTabs> @@ -142,13 +142,13 @@ meta="name=app/login/page.tsx" -Create the login/signup actions to hook up the form to the function which does the following: +Create the sign-in/sign-up actions to hook up the form to the function which does the following: - Retrieve the user's information. -- Send that information to Supabase as a signup request, which in turns sends a confirmation email. It uses [Magic Links](/docs/guides/auth/auth-email-passwordless#with-magic-link), so users can sign in with their email without using passwords. +- Send that information to Supabase as a sign-up request, which in turns sends a confirmation email. It uses [Magic Links](/docs/guides/auth/auth-email-passwordless#with-magic-link), so users can sign in with their email without using passwords. - Handle any error that arises. -Create the `action.ts` file in the `app/login` folder, which contains the login and signup functions and the `error/page.tsx` file, which displays an error message if the login or signup fails. +Create the `actions.ts` file in the `app/login` folder, which contains the sign-in and sign-up functions and the `error/page.tsx` file, which displays an error message if the sign-in or sign-up fails. <$CodeTabs> @@ -226,7 +226,7 @@ meta="name=app/account/page.tsx" ### Sign out -Create a route handler to handle the sign out from the server side, making sure to check if the user is logged in first. +Create a route handler to handle the sign-out from the server side, making sure to check if the user is signed in first. <$CodeSample path="/user-management/nextjs-user-management/app/auth/signout/route.ts" diff --git a/apps/docs/content/guides/getting-started/tutorials/with-nuxt-3.mdx b/apps/docs/content/guides/getting-started/tutorials/with-nuxt-3.mdx index 4541d2fc44b8f..10c7d8282ae6c 100644 --- a/apps/docs/content/guides/getting-started/tutorials/with-nuxt-3.mdx +++ b/apps/docs/content/guides/getting-started/tutorials/with-nuxt-3.mdx @@ -73,7 +73,7 @@ export default defineNuxtConfig({ ### Set up Auth component -Set up a Vue component to manage logins and sign ups. We'll use Magic Links, so users can sign in with their email without using passwords. +Set up a Vue component to manage sign-ins and sign-ups. We'll use Magic Links, so users can sign in with their email without using passwords. <$CodeTabs> diff --git a/apps/docs/content/guides/getting-started/tutorials/with-react.mdx b/apps/docs/content/guides/getting-started/tutorials/with-react.mdx index 43c27e7c43470..e4d66f541c224 100644 --- a/apps/docs/content/guides/getting-started/tutorials/with-react.mdx +++ b/apps/docs/content/guides/getting-started/tutorials/with-react.mdx @@ -58,9 +58,9 @@ meta="name=src/supabaseClient.js" An optional step is to update the CSS file `src/index.css` to make the app look better. You can find the full contents of this file [in the example repository](https://raw.githubusercontent.com/supabase/supabase/master/examples/user-management/react-user-management/src/index.css). -### Set up a login component +### Set up a sign-in component -You need a React component to manage logins and sign-ups. It uses [Magic Links](/docs/guides/auth/auth-email-passwordless#with-magic-link), so users can sign in with their email without using passwords. +You need a React component to manage sign-ins and sign-ups. It uses [Magic Links](/docs/guides/auth/auth-email-passwordless#with-magic-link), so users can sign in with their email without using passwords. diff --git a/apps/docs/content/guides/getting-started/tutorials/with-redwoodjs.mdx b/apps/docs/content/guides/getting-started/tutorials/with-redwoodjs.mdx index cb0774b4cd28d..9f482e115b699 100644 --- a/apps/docs/content/guides/getting-started/tutorials/with-redwoodjs.mdx +++ b/apps/docs/content/guides/getting-started/tutorials/with-redwoodjs.mdx @@ -230,9 +230,9 @@ export default Routes -### Set up a login component +### Set up a sign-in component -Set up a Redwood component to manage logins and sign ups. We'll use Magic Links, so users can sign in with their email without using passwords. +Set up a Redwood component to manage sign-ins and sign-ups. We'll use Magic Links, so users can sign in with their email without using passwords. ```bash yarn rw g component auth @@ -485,7 +485,7 @@ export default HomePage -What we're doing here is showing the sign in form if you aren't logged in and your account profile if you are. +What we're doing here is showing the sign-in form if you aren't signed in and your account profile if you are. diff --git a/apps/docs/content/guides/getting-started/tutorials/with-refine.mdx b/apps/docs/content/guides/getting-started/tutorials/with-refine.mdx index 62b3582985ccb..536167c2e30c5 100644 --- a/apps/docs/content/guides/getting-started/tutorials/with-refine.mdx +++ b/apps/docs/content/guides/getting-started/tutorials/with-refine.mdx @@ -15,7 +15,7 @@ If you get stuck while working through this guide, you can find the [full exampl ## About Refine -[Refine](https://github.com/refinedev/refine) is a React-based framework used to rapidly build data-heavy applications like admin panels, dashboards, storefronts and any type of CRUD apps. It separates app concerns into individual layers, each backed by a React context and respective provider object. For example, the auth layer represents a context served by a specific set of [`authProvider`](https://refine.dev/docs/tutorial/understanding-authprovider/index/) methods that carry out authentication and authorization actions such as logging in, logging out, getting roles data, etc. Similarly, the data layer offers another level of abstraction equipped with [`dataProvider`](https://refine.dev/docs/tutorial/understanding-dataprovider/index/) methods to handle CRUD operations at appropriate backend API endpoints. +[Refine](https://github.com/refinedev/refine) is a React-based framework used to rapidly build data-heavy applications like admin panels, dashboards, storefronts and any type of CRUD apps. It separates app concerns into individual layers, each backed by a React context and respective provider object. For example, the auth layer represents a context served by a specific set of [`authProvider`](https://refine.dev/docs/tutorial/understanding-authprovider/index/) methods that carry out authentication and authorization actions such as signing in, signing out, getting roles data, etc. Similarly, the data layer offers another level of abstraction equipped with [`dataProvider`](https://refine.dev/docs/tutorial/understanding-dataprovider/index/) methods to handle CRUD operations at appropriate backend API endpoints. Refine provides hassle-free integration with a Supabase backend with its supplementary [`@refinedev/supabase`](https://github.com/refinedev/refine/tree/main/packages/supabase) package. It generates `authProvider` and `dataProvider` methods at project initialization, so you don't need to spend much effort defining them yourself, choose Supabase as the backend service while creating the app with `create refine-app`. @@ -72,7 +72,7 @@ You can find the full contents of this file [in the example repository](https:// ### The `` component -In order to add login and user profile pages in this App, tweak the `` component inside `App.tsx`. +In order to add sign-in and user profile pages in this App, tweak the `` component inside `App.tsx`. The `App.tsx` file initially looks like this: @@ -87,7 +87,9 @@ import routerProvider, { } from '@refinedev/react-router' import { dataProvider, liveProvider } from '@refinedev/supabase' import { BrowserRouter, Route, Routes } from 'react-router' + import './App.css' + import authProvider from './authProvider' import { supabaseClient } from './utility' @@ -161,9 +163,9 @@ lines={[[1, -1]]} meta="name=src/authProvider.ts" /> -### Set up a login component +### Set up a sign-in component -As the app uses the headless Refine core package that comes with no supported UI framework set up a plain React component to manage logins and sign ups. +As the app uses the headless Refine core package that comes with no supported UI framework set up a plain React component to manage sign-ins and sign-ups. Create and edit `src/components/auth.tsx`: diff --git a/apps/docs/content/guides/getting-started/tutorials/with-solidjs.mdx b/apps/docs/content/guides/getting-started/tutorials/with-solidjs.mdx index 064a8c2c7325e..c95e2dd22b898 100644 --- a/apps/docs/content/guides/getting-started/tutorials/with-solidjs.mdx +++ b/apps/docs/content/guides/getting-started/tutorials/with-solidjs.mdx @@ -64,9 +64,9 @@ meta="name=src/supabaseClient.tsx" An optional step is to update the CSS file `src/index.css` to make the app look better. You can find the full contents of this file [in the example repository](https://raw.githubusercontent.com/supabase/supabase/master/examples/user-management/solid-user-management/src/index.css). -### Set up a login component +### Set up a sign-in component -Set up a SolidJS component to manage logins and sign ups using Magic Links, so users can sign in with their email without using passwords. +Set up a SolidJS component to manage sign-ins and sign-ups using Magic Links, so users can sign in with their email without using passwords. <$CodeTabs> diff --git a/apps/docs/content/guides/getting-started/tutorials/with-svelte.mdx b/apps/docs/content/guides/getting-started/tutorials/with-svelte.mdx index 278ce20350233..8107b1befb411 100644 --- a/apps/docs/content/guides/getting-started/tutorials/with-svelte.mdx +++ b/apps/docs/content/guides/getting-started/tutorials/with-svelte.mdx @@ -59,9 +59,9 @@ meta="name=src/supabaseClient.ts" Optionally, update the CSS file `src/app.css` to make the app look better. You can find the full contents of this file [in the example repository](https://raw.githubusercontent.com/supabase/supabase/master/examples/user-management/svelte-user-management/src/app.css). -### Set up a login component +### Set up a sign-in component -Set up a Svelte component to manage logins and sign ups. It uses Magic Links, so users can sign in with their email without using passwords. +Set up a Svelte component to manage sign-ins and sign-ups. It uses Magic Links, so users can sign in with their email without using passwords. <$CodeSample path="/user-management/svelte-user-management/src/lib/Auth.svelte" diff --git a/apps/docs/content/guides/getting-started/tutorials/with-sveltekit.mdx b/apps/docs/content/guides/getting-started/tutorials/with-sveltekit.mdx index 2b8e65cf30500..b9d3c1d6b2006 100644 --- a/apps/docs/content/guides/getting-started/tutorials/with-sveltekit.mdx +++ b/apps/docs/content/guides/getting-started/tutorials/with-sveltekit.mdx @@ -132,9 +132,9 @@ meta="name=src/routes/+layout.svelte" -### Set up a login page +### Set up a sign-in page -Create a magic link login/signup page for your application by updating the `routes/+page.svelte` file: +Create a magic link sign-in/sign-up page for your application by updating the `routes/+page.svelte` file: <$CodeTabs> diff --git a/apps/docs/content/guides/getting-started/tutorials/with-swift.mdx b/apps/docs/content/guides/getting-started/tutorials/with-swift.mdx index 45057d067c16c..b3e783bfe71cd 100644 --- a/apps/docs/content/guides/getting-started/tutorials/with-swift.mdx +++ b/apps/docs/content/guides/getting-started/tutorials/with-swift.mdx @@ -46,9 +46,9 @@ let supabase = SupabaseClient( -### Set up a login view +### Set up a sign-in view -Set up a SwiftUI view to manage logins and sign ups. +Set up a SwiftUI view to manage sign-ins and sign-ups. Users should be able to sign in using a magic link. <$CodeTabs> diff --git a/apps/docs/content/guides/getting-started/tutorials/with-vue-3.mdx b/apps/docs/content/guides/getting-started/tutorials/with-vue-3.mdx index 3013377e7a113..a76d052cde517 100644 --- a/apps/docs/content/guides/getting-started/tutorials/with-vue-3.mdx +++ b/apps/docs/content/guides/getting-started/tutorials/with-vue-3.mdx @@ -66,7 +66,7 @@ meta="name=src/supabase.js" An optional step is to update the CSS file `src/style.css` to make the app look better. You can find the full contents of this file [in the example repository](https://raw.githubusercontent.com/supabase/supabase/master/examples/user-management/vue3-user-management/src/style.css). -### Set up a login component +### Set up a sign-in component Set up an `src/components/Auth.vue` component to manage to add Magic Links as an option, so users can sign in with their email without using passwords. diff --git a/apps/docs/content/guides/integrations/stripe-projects.mdx b/apps/docs/content/guides/integrations/stripe-projects.mdx index 59ef301554598..eba4ea6cf70e7 100644 --- a/apps/docs/content/guides/integrations/stripe-projects.mdx +++ b/apps/docs/content/guides/integrations/stripe-projects.mdx @@ -57,4 +57,4 @@ Your Supabase project and organization work exactly like ones you create directl - Stripe Projects is in developer preview, so behavior may change. - Provisioning links to a Supabase organization by matching the email on the Stripe account to a Supabase account; there's no option in the CLI flow to choose a different existing organization. -- To access the Supabase dashboard for a new organization provisioned through Stripe Projects, use the `open` command (`stripe projects open supabase`). To log in to the Supabase dashboard directly without the CLI, follow the reset password flow for this account. +- To access the Supabase dashboard for a new organization provisioned through Stripe Projects, use the `open` command (`stripe projects open supabase`). To sign in to the Supabase dashboard directly without the CLI, follow the reset password flow for this account. diff --git a/apps/docs/content/guides/local-development/database-migrations.mdx b/apps/docs/content/guides/local-development/database-migrations.mdx index ebbf6cb9030b1..d1acbc83519bf 100644 --- a/apps/docs/content/guides/local-development/database-migrations.mdx +++ b/apps/docs/content/guides/local-development/database-migrations.mdx @@ -221,7 +221,7 @@ The last step is deploying these changes to a live Supabase project. You've been developing your project locally, making changes to your tables via migrations. It's time to deploy your project to the Supabase Platform and start scaling up to millions of users! Head over to [Supabase](/dashboard) and create a new project to deploy to. -### Log in to the Supabase CLI +### Sign in to the Supabase CLI <$CodeTabs> diff --git a/apps/docs/content/guides/local-development/declarative-database-schemas.mdx b/apps/docs/content/guides/local-development/declarative-database-schemas.mdx index 404648f57b0d3..1611efb5a2432 100644 --- a/apps/docs/content/guides/local-development/declarative-database-schemas.mdx +++ b/apps/docs/content/guides/local-development/declarative-database-schemas.mdx @@ -171,8 +171,8 @@ supabase migration up - - [Log in](/docs/reference/cli/supabase-login) via the Supabase CLI. + + [Sign in](/docs/reference/cli/supabase-login) via the Supabase CLI. diff --git a/apps/docs/content/guides/monitoring-and-debugging/debugging.mdx b/apps/docs/content/guides/monitoring-and-debugging/debugging.mdx index 1f995d36f8033..afed6fcdfc0e5 100644 --- a/apps/docs/content/guides/monitoring-and-debugging/debugging.mdx +++ b/apps/docs/content/guides/monitoring-and-debugging/debugging.mdx @@ -75,7 +75,7 @@ Supabase updates these troubleshooting guides continuously, so treat this table | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Empty `data` array with rows present; wrong rows returned; UPDATE/DELETE affects 0 rows; `42501` permission denied; `service_role` still blocked; policy not matching | RLS & access → `postgres_logs` | [Empty select array](/docs/guides/troubleshooting/why-is-my-select-returning-an-empty-data-array-and-i-have-data-in-the-table-xvOPgx) · [service_role hits RLS](/docs/guides/troubleshooting/why-is-my-service-role-key-client-getting-rls-errors-or-not-returning-data-7_1K9z) · [Database API 42501](/docs/guides/troubleshooting/database-api-42501-errors) · [RLS Simplified](/docs/guides/troubleshooting/rls-simplified-BJTcS8) · [Deprecated RLS features](/docs/guides/troubleshooting/deprecated-rls-features-Pm77Zs) | | `PGRST002`/`PGRST106`; "schema cache"; "could not find table/relationship"; new column or table not recognized; `42P01`; `520`; API returns nothing | Data API (PostgREST) → `edge_logs`, `postgres_logs` | [Refresh schema cache](/docs/guides/troubleshooting/refresh-postgrest-schema) · [PGRST002](/docs/guides/troubleshooting/postgrest-error-pgrst002-could-not-query-the-database-for-the-schema-cache-c396e9) · [New objects not recognized](/docs/guides/troubleshooting/postgrest-not-recognizing-new-columns-or-functions-bd75f5) · [42P01](/docs/guides/troubleshooting/resolving-42p01-relation-does-not-exist-error-W4_9-V) · [520 errors](/docs/guides/troubleshooting/fixing-520-errors-in-the-database-rest-api-Ur5-B2) · [API not returning](/docs/guides/troubleshooting/why-is-my-supabase-api-call-not-returning-PGzXw0) | -| Login/logout/session broken; JWT "invalid claim"/"missing sub"; cookies not sent; OAuth redirect wrong; OTP/magic-link expired; MFA/TOTP fails; auth `500`/`503`; emails not arriving | Auth → `auth_logs`, `postgres_logs` | [401 missing sub](/docs/guides/troubleshooting/auth-error-401-invalid-claim-missing-sub--AFwMR) · [500 auth errors](/docs/guides/troubleshooting/resolving-500-status-authentication-errors-7bU5U8) · [503 AuthRetryableFetchError](/docs/guides/troubleshooting/auth-error-503-authretryablefetcherror-51b88c) · [OTP expired](/docs/guides/troubleshooting/otp-verification-failures-token-has-expired-or-otp_expired-errors-5ee4d0) · [OAuth not redirecting](/docs/guides/troubleshooting/oauth-sign-in-isnt-redirecting-on-the-server-side-ShGMtr) · [No auth emails](/docs/guides/troubleshooting/not-receiving-auth-emails-from-the-supabase-project-OFSNzw) · [Next.js auth](/docs/guides/troubleshooting/how-do-you-troubleshoot-nextjs---supabase-auth-issues-riMCZV) | +| Sign-in/sign-out/session broken; JWT "invalid claim"/"missing sub"; cookies not sent; OAuth redirect wrong; OTP/magic-link expired; MFA/TOTP fails; auth `500`/`503`; emails not arriving | Auth → `auth_logs`, `postgres_logs` | [401 missing sub](/docs/guides/troubleshooting/auth-error-401-invalid-claim-missing-sub--AFwMR) · [500 auth errors](/docs/guides/troubleshooting/resolving-500-status-authentication-errors-7bU5U8) · [503 AuthRetryableFetchError](/docs/guides/troubleshooting/auth-error-503-authretryablefetcherror-51b88c) · [OTP expired](/docs/guides/troubleshooting/otp-verification-failures-token-has-expired-or-otp_expired-errors-5ee4d0) · [OAuth not redirecting](/docs/guides/troubleshooting/oauth-sign-in-isnt-redirecting-on-the-server-side-ShGMtr) · [No auth emails](/docs/guides/troubleshooting/not-receiving-auth-emails-from-the-supabase-project-OFSNzw) · [Next.js auth](/docs/guides/troubleshooting/how-do-you-troubleshoot-nextjs---supabase-auth-issues-riMCZV) | | `statement timeout`; duplicate key or sequence error; trigger errors; slow `ALTER`; blocked queries; disk/memory/swap pressure; index size | Database (Postgres) → `postgres_logs` | [Statement timeout](/docs/guides/troubleshooting/canceling-statement-due-to-statement-timeout-581wFv) · [Duplicate key / sequence](/docs/guides/troubleshooting/inserting-into-sequenceserial-table-causes-duplicate-key-violates-unique-constraint-error-pi6DnC) · [Blocked queries](/docs/guides/troubleshooting/how-to-check-if-my-queries-are-being-blocked-by-other-queries-NSKtR1) · [Disk not shrinking](/docs/guides/troubleshooting/disk-size-not-shrinking-after-deleting-data-135390) · [Autovacuum stalled](/docs/guides/troubleshooting/autovacuum-stalled-due-to-inactive-replication-slot-d55aa2) · [High CPU](/docs/guides/troubleshooting/high-cpu-usage) | | "too many connections"; "remaining connection slots"; `CONNECT_TIMEOUT`; pooler vs. direct connection; read-only transaction; `prepared statement already exists`; `no pg_hba.conf entry`; IPv4/IPv6; SASL/SCRAM | Connections & pooler → `supavisor_logs`, `postgres_logs` | [Too many connections](/docs/guides/troubleshooting/too-many-connections-for-database-postgres) · [Remaining slots](/docs/guides/troubleshooting/database-error-remaining-connection-slots-are-reserved-for-non-replication-superuser-connections-3V3nIb) · [Prepared statement exists](/docs/guides/troubleshooting/error-prepared-statement-xxx-already-exists-3laqeM) · [Read-only transaction](/docs/guides/troubleshooting/resolving-cannot-execute-update-in-a-read-only-transaction-on-transaction-pooler-connections-ef582c) · [CONNECT_TIMEOUT](/docs/guides/troubleshooting/troubleshooting-connect_timeout-or-hanging-queries-in-vercel-serverless-functions-775f92) · [Supavisor terminology](/docs/guides/troubleshooting/supavisor-and-connection-terminology-explained-9pr_ZO) | | Edge Function `401`/`404`/`500`/`503`/`504`/`546`; CPU/memory/wall-clock limit hit; won't deploy; boot error; WebSocket drop; `esm.sh` import fails | Edge Functions → `function_edge_logs`, `function_logs` | [401](/docs/guides/troubleshooting/edge-function-401-error-response) · [500](/docs/guides/troubleshooting/edge-function-500-error-response) · [503 boot](/docs/guides/troubleshooting/edge-function-503-response) · [504](/docs/guides/troubleshooting/edge-function-504-error-response) · [546 resource limit](/docs/guides/troubleshooting/edge-function-546-error-response) · [Shutdown reasons](/docs/guides/troubleshooting/edge-function-shutdown-reasons-explained) · [Deploy fails](/docs/guides/troubleshooting/edge-function-fails-deploy) · [esm.sh import](/docs/guides/troubleshooting/importing-stripe-or-other-modules-from-esmsh-on-deno-edge-functions-throws-an-error-TmbB5p) | diff --git a/apps/docs/content/guides/platform/custom-domains.mdx b/apps/docs/content/guides/platform/custom-domains.mdx index c294cbfbbb63d..90a2680095990 100644 --- a/apps/docs/content/guides/platform/custom-domains.mdx +++ b/apps/docs/content/guides/platform/custom-domains.mdx @@ -18,7 +18,7 @@ You can choose either a custom domain or vanity subdomain for each project. Custom domains change the way your project's URLs appear to your users. This is useful when: -- You are using [OAuth (Social Login)](/docs/guides/auth/social-login) with Supabase Auth and the project's URL is shown on the OAuth consent screen. +- You are using [OAuth (social login)](/docs/guides/auth/social-login) with Supabase Auth and the project's URL is shown on the OAuth consent screen. - You are creating APIs for third-party systems, for example, implementing webhooks or external API calls to your project via [Edge Functions](/docs/guides/functions). - You are storing URLs in a database or encoding them in QR codes. @@ -41,7 +41,7 @@ This example assumes your Supabase project is `abcdefghijklmnopqrst` with a corr To get started: 1. [Install](/docs/guides/local-development) the latest version of the Supabase CLI. -2. [Log in](/docs/guides/local-development/database-migrations#log-in-to-the-supabase-cli) to your Supabase account using the CLI. +2. [Sign in](/docs/guides/local-development/database-migrations#sign-in-to-the-supabase-cli) to your Supabase account using the CLI. 3. Ensure you have [Owner or Admin permissions](/docs/guides/platform/access-control#manage-team-members) for the project. 4. Get a custom domain from a DNS provider. Currently, only subdomains are supported. - Use `api.example.com` instead of `example.com`. @@ -153,7 +153,7 @@ Vanity subdomains allow you to present a basic branded experience, compared to c To get started: 1. [Install](/docs/guides/local-development) the latest version of the Supabase CLI. -1. [Log in](/docs/guides/local-development/database-migrations#log-in-to-the-supabase-cli) to your Supabase account using the CLI. +1. [Sign in](/docs/guides/local-development/database-migrations#sign-in-to-the-supabase-cli) to your Supabase account using the CLI. 1. Ensure that you have [Owner or Admin permissions](/docs/guides/platform/access-control#manage-team-members) for the project you'd like to set up a vanity subdomain for. 1. Ensure that your organization is on a paid plan (Pro/Team/Enterprise Plan) in the [Billing page of the Dashboard](/dashboard/org/_/billing). diff --git a/apps/docs/content/guides/platform/manage-your-usage/logs-ingest.mdx b/apps/docs/content/guides/platform/manage-your-usage/logs-ingest.mdx index c14b60cf62a4b..eb86f0ac58c7e 100644 --- a/apps/docs/content/guides/platform/manage-your-usage/logs-ingest.mdx +++ b/apps/docs/content/guides/platform/manage-your-usage/logs-ingest.mdx @@ -41,7 +41,7 @@ Every service in your Supabase project automatically generates logs — you don' - **Configure Postgres logging settings.** Postgres emits logs for connections, checkpoints, statements, and more — many of which can be tuned or disabled. Adjusting settings such as `log_connections`, `log_min_duration_statement`, and `log_statement` can significantly reduce Postgres log volume. See [Customizing Postgres configs](/docs/guides/database/custom-postgres-config) for the full list of configurable parameters. - **Reduce log-level verbosity** in your Edge Functions and server-side code (for example, `info` → `warn` in production). -- **Audit verbose logging in your application code.** Application-level logs forwarded to Supabase services count toward ingest. +- **Audit verbose application logging in your application code.** Application-level logs forwarded to Supabase services count toward ingest. - **Cap log payload size.** Large structured payloads can inflate GB-billed volume. - **Investigate spikes.** Use the [**Logs Explorer**](/dashboard/project/_/logs-explorer) in the Dashboard to find services or endpoints producing unusually high volume. diff --git a/apps/docs/content/guides/platform/manage-your-usage/monthly-active-users-sso.mdx b/apps/docs/content/guides/platform/manage-your-usage/monthly-active-users-sso.mdx index b99743659b0ff..531e905ff7923 100644 --- a/apps/docs/content/guides/platform/manage-your-usage/monthly-active-users-sso.mdx +++ b/apps/docs/content/guides/platform/manage-your-usage/monthly-active-users-sso.mdx @@ -5,7 +5,7 @@ title: 'Manage Monthly Active SSO Users usage' ## What you are charged for -You are charged for the number of distinct users who log in or refresh their token during the billing cycle using a SAML 2.0 compatible identity provider (e.g. Google Workspace, Microsoft Active Directory). Each unique user is counted only once per billing cycle, regardless of how many times they authenticate. These users are referred to as "SSO MAUs". +You are charged for the number of distinct users who sign in or refresh their token during the billing cycle using a SAML 2.0 compatible identity provider (e.g. Google Workspace, Microsoft Active Directory). Each unique user is counted only once per billing cycle, regardless of how many times they authenticate. These users are referred to as "SSO MAUs". ### Example diff --git a/apps/docs/content/guides/platform/manage-your-usage/monthly-active-users-third-party.mdx b/apps/docs/content/guides/platform/manage-your-usage/monthly-active-users-third-party.mdx index 417eaaf9f8097..d7746c5fff130 100644 --- a/apps/docs/content/guides/platform/manage-your-usage/monthly-active-users-third-party.mdx +++ b/apps/docs/content/guides/platform/manage-your-usage/monthly-active-users-third-party.mdx @@ -5,7 +5,7 @@ title: 'Manage Monthly Active Third-Party Users usage' ## What you are charged for -You are charged for the number of distinct users who log in or refresh their token during the billing cycle using a third-party authentication provider (Clerk, Firebase Auth, Auth0, AWS Cognito). Each unique user is counted only once per billing cycle, regardless of how many times they authenticate. These users are referred to as "Third-Party MAUs". +You are charged for the number of distinct users who sign in or refresh their token during the billing cycle using a third-party authentication provider (Clerk, Firebase Auth, Auth0, AWS Cognito). Each unique user is counted only once per billing cycle, regardless of how many times they authenticate. These users are referred to as "Third-Party MAUs". ### Example @@ -18,7 +18,7 @@ Your billing cycle runs from January 1 to January 31. Although User-1 was signed Third-Party MAU login screen Third-Party MAU login screen
  • 0 downtime
  • Users may need to log in again
    • |
    • Need to maintain 2 different Auth services, which may be more costly in the short-term
    • Need to maintain separate codepaths for the period of the migration
    • Some existing users may be inactive and have not signed in with the new provider. This means that you eventually need to backfill these users. However, this is a much smaller-scale one-off migration with lower risks since these users are inactive.
    | -| One-off |
    • No need to maintain 2 different auth services for an extended period of time
    |
    • Some downtime
    • Users will need to log in again. Risky for active users.
    | +| Rolling |
    • 0 downtime
    • Users may need to sign in again
    |
    • Need to maintain 2 different Auth services, which may be more costly in the short-term
    • Need to maintain separate codepaths for the period of the migration
    • Some existing users may be inactive and have not signed in with the new provider. This means that you eventually need to backfill these users. However, this is a much smaller-scale one-off migration with lower risks since these users are inactive.
    | +| One-off |
    • No need to maintain 2 different auth services for an extended period of time
    |
    • Some downtime
    • Users will need to sign in again. Risky for active users.
    | ## Migration steps @@ -49,12 +49,12 @@ To export password hashes and MFA factors, contact Auth0 support. ### Step 2: Import your users into Supabase Auth -The steps for importing your users depends on the login methods that you support. +The steps for importing your users depends on the sign-in methods that you support. See the following sections for how to import users with: -- [Password-based login](#password-based-methods) -- [Passwordless login](#passwordless-methods) +- [Password-based sign-in](#password-based-methods) +- [Passwordless sign-in](#passwordless-methods) - [OAuth](#oauth) #### Password-based methods @@ -73,7 +73,7 @@ Sign up new users using Supabase Auth's [signin methods](/docs/guides/auth/passw Migrate existing users to Supabase Auth. This requires two main steps: first, check which users need to be migrated, then create their accounts using the Supabase admin endpoints. 1. Get your Auth 0 user export and password hash export lists. -1. Filter for users who use password login. +1. Filter for users who use password sign-in. - Under the `identities` field in the user object, these users will have `auth0` as a provider. In the same identity object, you can find their Auth0 `user_id`. - Check that the user has a corresponding password hash by comparing their Auth0 `user_id` to the `oid` field in the password hash export. 1. Use Supabase Auth's [admin create user](/docs/reference/javascript/auth-admin-createuser) method to recreate the user in Supabase Auth. If the user has a confirmed email address or phone number, set `email_confirm` or `phone_confirm` to `true`. @@ -254,7 +254,7 @@ header="How do I migrate existing SAML Single Sign-On (SSO) connections?" id="saml" > -Customers may need to link their identity provider with Supabase Auth separately, but their users should still be able to sign-in as per-normal after authenticating with their identity provider. For more information about SSO with SAML 2.0, you can check out [this guide](/docs/guides/auth/enterprise-sso/auth-sso-saml). If you want to migrate your existing SAML SSO connections from Auth0 to Supabase Auth, reach out to us via support. +Customers may need to link their identity provider with Supabase Auth separately, but their users should still be able to sign in as per normal after authenticating with their identity provider. For more information about SSO with SAML 2.0, you can check out [this guide](/docs/guides/auth/enterprise-sso/auth-sso-saml). If you want to migrate your existing SAML SSO connections from Auth0 to Supabase Auth, reach out to us via support. diff --git a/apps/docs/content/guides/platform/migrating-to-supabase/firebase-auth.mdx b/apps/docs/content/guides/platform/migrating-to-supabase/firebase-auth.mdx index ad4399f9e2c0a..3e012208c5879 100644 --- a/apps/docs/content/guides/platform/migrating-to-supabase/firebase-auth.mdx +++ b/apps/docs/content/guides/platform/migrating-to-supabase/firebase-auth.mdx @@ -36,7 +36,7 @@ Supabase provides several [tools](https://github.com/supabase-community/firebase ## Generate a Firebase private key [#generate-firebase-private-key] -1. Log in to your [Firebase Console](https://console.firebase.google.com/project) and open your project. +1. Sign in to your [Firebase Console](https://console.firebase.google.com/project) and open your project. 1. Click the gear icon next to **Project Overview** in the sidebar and select **Project Settings**. 1. Click **Service Accounts** and select **Firebase Admin SDK**. 1. Click **Generate new private key**. @@ -44,7 +44,7 @@ Supabase provides several [tools](https://github.com/supabase-community/firebase ## Save your Firebase password hash parameters [#save-firebase-hash-parameters] -1. Log in to your [Firebase Console](https://console.firebase.google.com/project) and open your project. +1. Sign in to your [Firebase Console](https://console.firebase.google.com/project) and open your project. 1. Select **Authentication** (Build section) in the sidebar. 1. Select **Users** in the top menu. 1. At the top right of the users list, open the menu (3 dots) and click **Password hash parameters**. diff --git a/apps/docs/content/guides/platform/migrating-to-supabase/firebase-storage.mdx b/apps/docs/content/guides/platform/migrating-to-supabase/firebase-storage.mdx index 12a84f98cadba..82d4bbdaab7f4 100644 --- a/apps/docs/content/guides/platform/migrating-to-supabase/firebase-storage.mdx +++ b/apps/docs/content/guides/platform/migrating-to-supabase/firebase-storage.mdx @@ -25,7 +25,7 @@ Supabase provides several [tools](https://github.com/supabase-community/firebase ## Generate a Firebase private key [#generate-firebase-private-key] -1. Log in to your [Firebase Console](https://console.firebase.google.com/project) and open your project. +1. Sign in to your [Firebase Console](https://console.firebase.google.com/project) and open your project. 1. Click the gear icon next to **Project Overview** in the sidebar and select **Project Settings**. 1. Click **Service Accounts** and select **Firebase Admin SDK**. 1. Click **Generate new private key**. diff --git a/apps/docs/content/guides/platform/migrating-to-supabase/firestore-data.mdx b/apps/docs/content/guides/platform/migrating-to-supabase/firestore-data.mdx index 647a5c880cb60..6579d26323d7b 100644 --- a/apps/docs/content/guides/platform/migrating-to-supabase/firestore-data.mdx +++ b/apps/docs/content/guides/platform/migrating-to-supabase/firestore-data.mdx @@ -35,7 +35,7 @@ The Firestore `collection` is "flattened" and converted to a table with basic co ## Generate a Firebase private key [#generate-firebase-private-key] -1. Log in to your [Firebase Console](https://console.firebase.google.com/project) and open your project. +1. Sign in to your [Firebase Console](https://console.firebase.google.com/project) and open your project. 1. Click the gear icon next to **Project Overview** in the sidebar and select **Project Settings**. 1. Click **Service Accounts** and select **Firebase Admin SDK**. 1. Click **Generate new private key**. diff --git a/apps/docs/content/guides/platform/migrating-to-supabase/heroku.mdx b/apps/docs/content/guides/platform/migrating-to-supabase/heroku.mdx index 036416e874612..99209b9e86dbe 100644 --- a/apps/docs/content/guides/platform/migrating-to-supabase/heroku.mdx +++ b/apps/docs/content/guides/platform/migrating-to-supabase/heroku.mdx @@ -23,7 +23,7 @@ Alternatively, use the [Heroku to Supabase migration tool](https://migrate.supab ## Retrieve your Heroku database credentials [#retrieve-heroku-credentials] -1. Log in to your [Heroku account](https://heroku.com) and select the project you want to migrate. +1. Sign in to your [Heroku account](https://heroku.com) and select the project you want to migrate. 1. Click **Resources** in the menu and select your **Heroku Postgres** database. 1. Click **Settings** in the menu. 1. Click **View Credentials** and save the following information: diff --git a/apps/docs/content/guides/platform/migrating-to-supabase/mssql.mdx b/apps/docs/content/guides/platform/migrating-to-supabase/mssql.mdx index e555d0b662210..42c3ed8481165 100644 --- a/apps/docs/content/guides/platform/migrating-to-supabase/mssql.mdx +++ b/apps/docs/content/guides/platform/migrating-to-supabase/mssql.mdx @@ -10,7 +10,7 @@ This guide aims to demonstrate the process of transferring your Microsoft SQL Se Before you begin the migration, you need to collect essential information about your MSSQL database. Follow these steps: -1. Log in to your MSSQL database provider. +1. Sign in to your MSSQL database provider. 1. Locate and note the following database details: - Hostname or IP address - Database name diff --git a/apps/docs/content/guides/platform/migrating-to-supabase/mysql.mdx b/apps/docs/content/guides/platform/migrating-to-supabase/mysql.mdx index 24a66b899f6df..68eabc48da2f9 100644 --- a/apps/docs/content/guides/platform/migrating-to-supabase/mysql.mdx +++ b/apps/docs/content/guides/platform/migrating-to-supabase/mysql.mdx @@ -10,7 +10,7 @@ This guide aims to exhibit the process of transferring your MySQL database to Su Before you begin the migration, you need to collect essential information about your MySQL database. Follow these steps: -1. Log in to your MySQL database provider. +1. Sign in to your MySQL database provider. 1. Locate and note the following database details: - Hostname or IP address diff --git a/apps/docs/content/guides/platform/migrating-to-supabase/neon.mdx b/apps/docs/content/guides/platform/migrating-to-supabase/neon.mdx index 73907c736ea63..0bb1501bddefe 100644 --- a/apps/docs/content/guides/platform/migrating-to-supabase/neon.mdx +++ b/apps/docs/content/guides/platform/migrating-to-supabase/neon.mdx @@ -8,7 +8,7 @@ This guide demonstrates how to migrate your Neon database to Supabase to get the ## Retrieve your Neon database credentials [#retrieve-credentials] -1. Log in to your Neon Console [https://console.neon.tech/login](https://console.neon.tech/login). +1. Sign in to your Neon Console [https://console.neon.tech/login](https://console.neon.tech/login). 1. Select **Projects** on the left. 1. Click on your project in the list. 1. From your Project Dashboard find your **Connection string** and click **Copy snippet** to copy it to the clipboard (do not check "pooled connection"). diff --git a/apps/docs/content/guides/platform/migrating-to-supabase/render.mdx b/apps/docs/content/guides/platform/migrating-to-supabase/render.mdx index 1e12f8e6ca286..e3f678a412f47 100644 --- a/apps/docs/content/guides/platform/migrating-to-supabase/render.mdx +++ b/apps/docs/content/guides/platform/migrating-to-supabase/render.mdx @@ -12,7 +12,7 @@ This guide demonstrates how to migrate from Render to Supabase to get the most o ## Retrieve your Render database credentials [#retrieve-render-credentials] -1. Log in to your [Render account](https://render.com) and select the project you want to migrate. +1. Sign in to your [Render account](https://render.com) and select the project you want to migrate. 1. Click **Dashboard** in the menu and click in your **Postgres** database. 1. Scroll down in the **Info** tab. 1. Click on **PSQL Command** and edit it adding the content after `PSQL_COMMAND=`. diff --git a/apps/docs/content/guides/platform/migrating-to-supabase/vercel-postgres.mdx b/apps/docs/content/guides/platform/migrating-to-supabase/vercel-postgres.mdx index dbd73ffa4006e..bd215b392aa7b 100644 --- a/apps/docs/content/guides/platform/migrating-to-supabase/vercel-postgres.mdx +++ b/apps/docs/content/guides/platform/migrating-to-supabase/vercel-postgres.mdx @@ -8,7 +8,7 @@ This guide demonstrates how to migrate your Vercel Postgres database to Supabase ## Retrieve your Vercel Postgres database credentials [#retrieve-credentials] -1. Log in to your Vercel Dashboard [https://vercel.com/login](https://vercel.com/login). +1. Sign in to your Vercel Dashboard [https://vercel.com/login](https://vercel.com/login). 1. Click on the **Storage** tab. 1. Click on your Postgres Database. 1. Under the **Quickstart** section, select **psql** then click **Show Secret** to reveal your database password. diff --git a/apps/docs/content/guides/platform/migrating-within-supabase/backup-restore.mdx b/apps/docs/content/guides/platform/migrating-within-supabase/backup-restore.mdx index 5a38ace3123ef..e6415d7258dbf 100644 --- a/apps/docs/content/guides/platform/migrating-within-supabase/backup-restore.mdx +++ b/apps/docs/content/guides/platform/migrating-within-supabase/backup-restore.mdx @@ -299,7 +299,7 @@ DROP ROLE IF EXISTS cli_login_postgres; - + With the Supabase CLI [Supabase CLI](/docs/guides/local-development/cli/getting-started), run: ```bash supabase login diff --git a/apps/docs/content/guides/platform/multi-factor-authentication.mdx b/apps/docs/content/guides/platform/multi-factor-authentication.mdx index d460dcb623289..fd9a099c51e65 100644 --- a/apps/docs/content/guides/platform/multi-factor-authentication.mdx +++ b/apps/docs/content/guides/platform/multi-factor-authentication.mdx @@ -18,7 +18,7 @@ Currently, Supabase supports adding a unique time-based one-time password (TOTP) ## Enable MFA -You can enable MFA for your user account under your [Supabase account settings](/dashboard/account/security). Enabling MFA will result in all other user sessions to be automatically logged out and forced to sign-in again with MFA. +You can enable MFA for your user account under your [Supabase account settings](/dashboard/account/security). Enabling MFA will result in all other user sessions to be automatically logged out and forced to sign in again with MFA. @@ -32,7 +32,7 @@ For security reasons, we will not be able to restore access to your account if y -## Login with MFA +## Sign in with MFA Once you've enabled MFA for your Supabase user account, you will be prompted to enter your second factor challenge code as seen in your preferred TOTP app. @@ -40,7 +40,7 @@ If you are an organization owner and on the Pro, Team or Enterprise plan, you ca ## Disable MFA -You can disable MFA for your user account under your [Supabase account settings](/dashboard/account/security). On subsequent login attempts, you will not be prompted to enter an MFA code. +You can disable MFA for your user account under your [Supabase account settings](/dashboard/account/security). On subsequent sign-in attempts, you will not be prompted to enter an MFA code. diff --git a/apps/docs/content/guides/platform/network-restrictions.mdx b/apps/docs/content/guides/platform/network-restrictions.mdx index 1427441a21560..7a3ec0bcc8813 100644 --- a/apps/docs/content/guides/platform/network-restrictions.mdx +++ b/apps/docs/content/guides/platform/network-restrictions.mdx @@ -28,7 +28,7 @@ To configure network restrictions with the dashboard: To configure network restrictions with the CLI: 1. [Install](/docs/guides/local-development) the Supabase CLI 1.22.0+. -1. [Log in](/docs/guides/local-development/database-migrations#log-in-to-the-supabase-cli) to your Supabase account. +1. [Sign in](/docs/guides/local-development/database-migrations#sign-in-to-the-supabase-cli) to your Supabase account. 1. If your project was created before December 23, 2022, [upgrade it to the latest Supabase version](/docs/guides/platform/upgrading) before using network restrictions. 1. Ensure you have [Owner or Admin permissions](/docs/guides/platform/access-control#manage-team-members) for the project. diff --git a/apps/docs/content/guides/platform/privatelink.mdx b/apps/docs/content/guides/platform/privatelink.mdx index e1ac45325ed3f..08e22a1eb0789 100644 --- a/apps/docs/content/guides/platform/privatelink.mdx +++ b/apps/docs/content/guides/platform/privatelink.mdx @@ -59,7 +59,7 @@ Select **View connection** to see the VPC Lattice resource configuration ID and Supabase will send you an AWS Resource Share containing the VPC Lattice Resource Configurations for your projects. To accept this share: -1. Login to your AWS Management Console, ensure you are in the AWS region where your Supabase project is located +1. Sign in to your AWS Management Console, ensure you are in the AWS region where your Supabase project is located 2. Navigate to the AWS Resource Access Manager (RAM) console {/* supa-mdx-lint-disable-next-line Rule004ExcludeWords */} 3. Go to [Shared with me > Resource shares](https://console.aws.amazon.com/ram/home#SharedResourceShares) diff --git a/apps/docs/content/guides/platform/ssl-enforcement.mdx b/apps/docs/content/guides/platform/ssl-enforcement.mdx index 726596f60bca4..f911eef9f0554 100644 --- a/apps/docs/content/guides/platform/ssl-enforcement.mdx +++ b/apps/docs/content/guides/platform/ssl-enforcement.mdx @@ -62,7 +62,7 @@ curl -X PUT "https://api.supabase.com/v1/projects/$PROJECT_REF/ssl-enforcement" To get started: 1. [Install](/docs/guides/local-development) the Supabase CLI 1.37.0+. -1. [Log in](/docs/guides/local-development/database-migrations#log-in-to-the-supabase-cli) to your Supabase account using the CLI. +1. [Sign in](/docs/guides/local-development/database-migrations#sign-in-to-the-supabase-cli) to your Supabase account using the CLI. 1. Ensure that you have [Owner or Admin permissions](/docs/guides/platform/access-control#manage-team-members) for the project that you are enabling SSL enforcement. ### Check enforcement status diff --git a/apps/docs/content/guides/platform/sso.mdx b/apps/docs/content/guides/platform/sso.mdx index 881157813373b..d623c5fe50a5a 100644 --- a/apps/docs/content/guides/platform/sso.mdx +++ b/apps/docs/content/guides/platform/sso.mdx @@ -9,7 +9,7 @@ Looking for docs on how to add Single Sign-On support in your Supabase project? -Supabase offers single sign-on (SSO) as a login option to provide additional account security for your team. This allows company administrators to enforce the use of an identity provider when logging into Supabase. SSO improves the onboarding and offboarding experience of the company as the employee only needs a single set of credentials to access third-party applications or tools which can also be revoked by an administrator. +Supabase offers single sign-on (SSO) as a sign-in option to provide additional account security for your team. This allows company administrators to enforce the use of an identity provider when signing in to Supabase. SSO improves the onboarding and offboarding experience of the company as the employee only needs a single set of credentials to access third-party applications or tools which can also be revoked by an administrator. @@ -40,13 +40,13 @@ After configuring your SSO provider, thorough testing is essential. See our [SSO -## Choosing your login flow +## Choosing your sign-in flow -Supabase supports two SSO login flows: **IdP-initiated** and **SP-initiated**. You can enable one or both depending on your organization's needs. +Supabase supports two SSO sign-in flows: **IdP-initiated** and **SP-initiated**. You can enable one or both depending on your organization's needs. -### IdP-initiated login (recommended) +### IdP-initiated sign-in (recommended) -Users start their login from your identity provider (Okta, Azure AD, Google Workspace) by clicking an app tile or bookmark. This is the **simplest and most common configuration** - it requires no domain configuration and works automatically once SSO is enabled. +Users start their sign-in from your identity provider (Okta, Azure AD, Google Workspace) by clicking an app tile or bookmark. This is the **simplest and most common configuration** - it requires no domain configuration and works automatically once SSO is enabled. **Best for:** @@ -54,9 +54,9 @@ Users start their login from your identity provider (Okta, Azure AD, Google Work - Multiple SAML apps per domain (Dev, Staging, Prod) - Simplest user experience -### SP-initiated login +### SP-initiated sign-in -Users start their login at supabase.com by entering their email address, then are redirected to your identity provider. This flow requires configuring email domains to route users to the correct IdP. +Users start their sign-in at supabase.com by entering their email address, then are redirected to your identity provider. This flow requires configuring email domains to route users to the correct IdP. **Best for:** @@ -67,16 +67,16 @@ Users start their login at supabase.com by entering their email address, then ar ### Need help choosing? - **Quick decision:** Start with IdP-initiated only (the default). It works for 90% of use cases. -- **Detailed guidance:** See [Choosing the Right Login Flow](/docs/guides/platform/sso/choosing-login-flow) for scenario-based recommendations. -- **Technical details:** Read [Understanding SSO Login Flows](/docs/guides/platform/sso/login-flows) for in-depth explanations. +- **Detailed guidance:** See [Choosing the Right Sign-in Flow](/docs/guides/platform/sso/choosing-login-flow) for scenario-based recommendations. +- **Technical details:** Read [Understanding SSO Sign-in Flows](/docs/guides/platform/sso/login-flows) for in-depth explanations. ## Key configuration options -- **Login flows** - Choose between IdP-initiated (users start from identity provider), SP-initiated (users start at supabase.com), or both. IdP-initiated is recommended for most organizations and requires no domain configuration. See [Choosing the Right Login Flow](/docs/guides/platform/sso/choosing-login-flow) for guidance. -- **Email domains** - Required only if you enable SP-initiated login. You can associate one or more email domains with your SSO provider. Users with matching email addresses can sign in via SSO at supabase.com. Not required for IdP-initiated flow. -- **Auto-join** - Optionally allow users with a matching domain to join your organization automatically when they sign in via SSO. This applies on every login, not only on first signup. +- **Sign-in flows** - Choose between IdP-initiated (users start from identity provider), SP-initiated (users start at supabase.com), or both. IdP-initiated is recommended for most organizations and requires no domain configuration. See [Choosing the Right Sign-in Flow](/docs/guides/platform/sso/choosing-login-flow) for guidance. +- **Email domains** - Required only if you enable SP-initiated sign-in. You can associate one or more email domains with your SSO provider. Users with matching email addresses can sign in via SSO at supabase.com. Not required for IdP-initiated flow. +- **Auto-join** - Optionally allow users with a matching domain to join your organization automatically when they sign in via SSO. This applies on every sign-in, not only on first sign-up. - **Default role for auto-joined users** - Choose the role (e.g., `Read-only`, `Developer`, `Administrator`, `Owner`) that automatically joined users receive. We recommend using `Developer` as the default (principle of least privilege) and promoting users individually as needed. Refer to [access control](/docs/guides/platform/access-control) for more information about roles. -- **Invitation types** - When inviting users to your organization, you can explicitly choose whether the invitation requires SSO authentication or allows non-SSO login (password/social). This enables mixed authentication organizations with both SSO and non-SSO users. +- **Invitation types** - When inviting users to your organization, you can explicitly choose whether the invitation requires SSO authentication or allows non-SSO sign-in (password/social). This enables mixed authentication organizations with both SSO and non-SSO users. ## How SSO works in Supabase @@ -95,10 +95,10 @@ When SSO is enabled for an organization: 1. Create or verify at least one non-SSO owner account exists (required for safety) 2. Configure your SSO provider following one of our [provider-specific guides](#supported-providers) 3. Start with auto-join **disabled** to test the configuration -4. Test SSO login with your own account +4. Test SSO sign-in with your own account 5. Once confirmed working, enable auto-join if desired 6. Thoroughly test using our [SSO Testing and Best Practices](/docs/guides/platform/sso/testing-best-practices) guide -7. Invite users to the organization or let them auto-join on login +7. Invite users to the organization or let them auto-join on sign-in @@ -108,9 +108,9 @@ If a user is already a member of the organization under a non-SSO account, they -Each user account verified using an SSO identity provider will not be legible for [identity linking](/docs/guides/auth/auth-identity-linking) to existing user accounts in the system. That is, if a user `valid.email@supabase.io` had signed up with a password, and then uses their company SSO login with your project, there will be two `valid.email@supabase.io` user accounts in the system. +Each user account verified using an SSO identity provider will not be eligible for [identity linking](/docs/guides/auth/auth-identity-linking) to existing user accounts in the system. That is, if a user `valid.email@supabase.io` had signed up with a password, and then uses their company SSO sign-in with your project, there will be two `valid.email@supabase.io` user accounts in the system. -Users will need to ensure they are logged in with the correct account when accessing organizations/projects. +Users will need to ensure they are signed in with the correct account when accessing organizations/projects. @@ -124,7 +124,7 @@ The system requires at least one non-SSO owner account before allowing SSO provi Before disabling or deleting SSO: -- Verify a non-SSO owner account exists and can log in +- Verify a non-SSO owner account exists and can sign in - Communicate to affected users in advance - Consider whether disabling is better than deleting if the change is temporary @@ -141,7 +141,7 @@ To revoke access for a specific SSO user without disabling the provider entirely Before rolling out SSO to your organization, we strongly recommend thorough testing and following security best practices. Our comprehensive guide covers: -- Step-by-step testing procedures for SSO login, auto-join, and invitations +- Step-by-step testing procedures for SSO sign-in, auto-join, and invitations - Troubleshooting common issues (many of which previously required support intervention) - Security best practices including certificate monitoring and domain configuration - Operational guidance for making SSO changes safely diff --git a/apps/docs/content/guides/platform/sso/azure.mdx b/apps/docs/content/guides/platform/sso/azure.mdx index 913f534ed2416..db6f954bdd38a 100644 --- a/apps/docs/content/guides/platform/sso/azure.mdx +++ b/apps/docs/content/guides/platform/sso/azure.mdx @@ -128,13 +128,13 @@ Fill out the Attribute Mapping section using the **Azure** preset. ![Attribute mapping configuration](/docs/img/sso-dashboard-configure-attributes-azure.png) -## Step 12: Join organization on signup (optional) [#dashboard-configure-autojoin] +## Step 12: Join organization on sign-up (optional) [#dashboard-configure-autojoin] -By default this setting is disabled, users logging in via SSO will not be added to your organization automatically. +By default this setting is disabled, users signing in via SSO will not be added to your organization automatically. ![Auto-join disabled](/docs/img/sso-dashboard-configure-autojoin-disabled.png) -Toggle this on if you want SSO-authenticated users to be **automatically added to your organization** when they log in via SSO. Auto-join applies on **every login**, not only on first signup - this makes it safe to test SSO before enabling this feature. +Toggle this on if you want SSO-authenticated users to be **automatically added to your organization** when they sign in via SSO. Auto-join applies on **every sign-in**, not only on first sign-up - this makes it safe to test SSO before enabling this feature. ![Auto-join enable](/docs/img/sso-dashboard-configure-autojoin-enabled.png) diff --git a/apps/docs/content/guides/platform/sso/choosing-login-flow.mdx b/apps/docs/content/guides/platform/sso/choosing-login-flow.mdx index 2e6d6c65ed3aa..6cc84c067dca3 100644 --- a/apps/docs/content/guides/platform/sso/choosing-login-flow.mdx +++ b/apps/docs/content/guides/platform/sso/choosing-login-flow.mdx @@ -1,9 +1,9 @@ --- -title: 'Choosing the Right SSO Login Flow' -description: 'Quick reference guide to help you choose between IdP-initiated, SP-initiated, or both login flows based on your use case.' +title: 'Choosing the Right SSO Sign-in Flow' +description: 'Quick reference guide to help you choose between IdP-initiated, SP-initiated, or both sign-in flows based on your use case.' --- -Not sure which single sign-on (SSO) login flow to enable? This guide maps common enterprise scenarios to the recommended configuration. +Not sure which single sign-on (SSO) sign-in flow to enable? This guide maps common enterprise scenarios to the recommended configuration. @@ -92,7 +92,7 @@ Do users need to start login at supabase.com? 3. Configure identity provider metadata 4. Create Supabase app tile in your IdP -**Result:** One-click SSO login for all users. +**Result:** One-click SSO sign-in for all users. --- @@ -101,7 +101,7 @@ Do users need to start login at supabase.com? **Your situation:** - Users frequently bookmark supabase.com directly -- You want to support starting login from Supabase +- You want to support starting sign-in from Supabase - Single domain, single organization **Recommended configuration:** Enable both flows ✅ @@ -120,7 +120,7 @@ Do users need to start login at supabase.com? 4. Configure identity provider metadata 5. Create Supabase app tile in your IdP (optional but recommended) -**Result:** Users can start login from either Supabase or IdP. +**Result:** Users can start sign-in from either Supabase or IdP. --- @@ -128,7 +128,7 @@ Do users need to start login at supabase.com? **Your situation:** -- Currently using password-based login +- Currently using password-based sign-in - Transitioning to SSO - Users are used to starting at supabase.com @@ -136,7 +136,7 @@ Do users need to start login at supabase.com? **Why:** -- Familiar login starting point for existing users +- Familiar sign-in starting point for existing users - Gradual transition to IdP-based access - Can promote IdP tiles after users adapt @@ -267,7 +267,7 @@ Communicate clearly which authentication method each user should use. ## Testing your configuration -After choosing your login flow, thoroughly test: +After choosing your sign-in flow, thoroughly test: 1. **IdP-initiated:** Click app tile in IdP → Verify redirect to Supabase 2. **SP-initiated:** Go to supabase.com/sign-in-sso → Enter email → Verify IdP redirect @@ -278,7 +278,7 @@ See our comprehensive [SSO Testing and Best Practices guide](/docs/guides/platfo ## When to change configuration -You can safely change login flow configuration at any time: +You can safely change sign-in flow configuration at any time: ### Adding SP-initiated to IdP-only @@ -314,7 +314,7 @@ If you need help choosing the right configuration for your organization, contact ## Next steps -- **Understand the technical details:** Read [Understanding SSO Login Flows](/docs/guides/platform/sso/login-flows) +- **Understand the technical details:** Read [Understanding SSO Sign-in Flows](/docs/guides/platform/sso/login-flows) - **Configure your provider:** Follow our [provider-specific guides](/docs/guides/platform/sso#supported-providers) - **Test your setup:** Review [SSO Testing and Best Practices](/docs/guides/platform/sso/testing-best-practices) - **Enable auto-join:** Configure [auto-join settings](/docs/guides/platform/sso#key-configuration-options) diff --git a/apps/docs/content/guides/platform/sso/enterprise-mcp-authentication.mdx b/apps/docs/content/guides/platform/sso/enterprise-mcp-authentication.mdx index 1b887d93a7d30..e70cc5997bb83 100644 --- a/apps/docs/content/guides/platform/sso/enterprise-mcp-authentication.mdx +++ b/apps/docs/content/guides/platform/sso/enterprise-mcp-authentication.mdx @@ -37,7 +37,7 @@ Before members can use enterprise-managed authentication: ## How it works -1. **Member signs in to the MCP client via your IdP**, using the same SSO login your members already use, over OpenID Connect or SAML. The IdP returns an identity token to the MCP client. +1. **Member signs in to the MCP client via your IdP**, using the same SSO sign-in your members already use, over OpenID Connect or SAML. The IdP returns an identity token to the MCP client. 2. **MCP client exchanges that identity token for an ID-JAG, at the IdP.** This is a separate request the client makes to the IdP (an [RFC 8693](https://datatracker.ietf.org/doc/html/rfc8693) token exchange), asking for a token scoped specifically to Supabase. The IdP checks its own policy before issuing one. 3. **IdP returns the ID-JAG to the MCP client.** 4. **MCP client presents the ID-JAG to Supabase's OAuth server**, using it as a [JWT authorization grant](https://datatracker.ietf.org/doc/html/rfc7523), with no interactive consent screen. @@ -54,7 +54,7 @@ Without it, every member has to manually connect and authorize the MCP client ag - **No central control**: admins can't see or revoke the MCP client's access at the organization level; it's spread across individual user approvals. - **Inconsistent access**: a member's access through the MCP client isn't guaranteed to stay in sync with the role your IdP already assigns them. -With enterprise-managed authentication, an organization owner authorizes the MCP client once for the whole organization. From then on, access follows your existing SSO login, with no separate approval and no manual reconnection when a token expires. +With enterprise-managed authentication, an organization owner authorizes the MCP client once for the whole organization. From then on, access follows your existing SSO sign-in, with no separate approval and no manual reconnection when a token expires. ## Configuring your ID-JAG issuer diff --git a/apps/docs/content/guides/platform/sso/gsuite.mdx b/apps/docs/content/guides/platform/sso/gsuite.mdx index d28c1fda108ce..9702c7096e5ce 100644 --- a/apps/docs/content/guides/platform/sso/gsuite.mdx +++ b/apps/docs/content/guides/platform/sso/gsuite.mdx @@ -63,7 +63,7 @@ Fill out these service provider details on the next screen. ## Step 6: Configure attribute mapping [#configure-attribute-mapping] -Attribute mappings allow Supabase to get information about your Google Workspace users on each login. +Attribute mappings allow Supabase to get information about your Google Workspace users on each sign-in. **A _Primary email_ to `email` mapping is required.** Other mappings shown below are optional and configurable depending on your Google Workspace setup. If in doubt, replicate the same config as shown. @@ -136,15 +136,15 @@ If you did not customize your settings you may save some time by clicking the ** -**Recommended workflow:** Start with auto-join **disabled** to test your SSO configuration. Once SSO login is working correctly, enable auto-join if desired. +**Recommended workflow:** Start with auto-join **disabled** to test your SSO configuration. Once SSO sign-in is working correctly, enable auto-join if desired. -By default this setting is disabled, users logging in via SSO will not be added to your organization automatically. +By default this setting is disabled, users signing in via SSO will not be added to your organization automatically. ![Auto-join disabled](/docs/img/sso-dashboard-configure-autojoin-disabled.png) -Toggle this on if you want SSO-authenticated users to be **automatically added to your organization** when they log in via SSO. Auto-join applies on **every login**, not only on first signup - this makes it safe to test SSO before enabling this feature. +Toggle this on if you want SSO-authenticated users to be **automatically added to your organization** when they sign in via SSO. Auto-join applies on **every sign-in**, not only on first signup - this makes it safe to test SSO before enabling this feature. ![Auto-join enable](/docs/img/sso-dashboard-configure-autojoin-enabled.png) diff --git a/apps/docs/content/guides/platform/sso/login-flows.mdx b/apps/docs/content/guides/platform/sso/login-flows.mdx index b67b0fab73475..44bd9031357a9 100644 --- a/apps/docs/content/guides/platform/sso/login-flows.mdx +++ b/apps/docs/content/guides/platform/sso/login-flows.mdx @@ -1,29 +1,29 @@ --- -title: 'Understanding SSO Login Flows' -description: 'Learn about IdP-initiated and SP-initiated SSO login flows and when to use each approach.' +title: 'Understanding SSO Sign-in Flows' +description: 'Learn about IdP-initiated and SP-initiated SSO sign-in flows and when to use each approach.' --- -When configuring SSO for your organization, you can choose between two different login flows: **identity provider (IdP)-initiated** and **service provider (SP)-initiated**. Understanding the difference helps you provide the best experience for your users. +When configuring SSO for your organization, you can choose between two different sign-in flows: **identity provider (IdP)-initiated** and **service provider (SP)-initiated**. Understanding the difference helps you provide the best experience for your users. -Most enterprises use IdP-initiated flow for its simplicity and better user experience. Enable SP-initiated only if you need users to start their login journey at supabase.com. +Most enterprises use IdP-initiated flow for its simplicity and better user experience. Enable SP-initiated only if you need users to start their sign-in journey at supabase.com. -See our [Choosing the Right Login Flow guide](/docs/guides/platform/sso/choosing-login-flow) for use case examples. +See our [Choosing the Right Sign-in Flow guide](/docs/guides/platform/sso/choosing-login-flow) for use case examples. -## Overview of login flows +## Overview of sign-in flows ### IdP-initiated (Identity Provider Initiated) -With IdP-initiated flow, users start their login journey from your identity provider (Okta, Azure AD, Google Workspace, etc.) and are directly authenticated into Supabase. +With IdP-initiated flow, users start their sign-in journey from your identity provider (Okta, Azure AD, Google Workspace, etc.) and are directly authenticated into Supabase. **User experience:** 1. User opens their identity provider dashboard (e.g., Okta homepage, Azure MyApps) 2. User clicks the Supabase app tile or bookmark -3. User is immediately logged into Supabase (if already authenticated with IdP) +3. User is immediately signed in to Supabase (if already authenticated with IdP) **Key characteristics:** @@ -49,7 +49,7 @@ With SP-initiated flow, users start at supabase.com, enter their email address, - ✅ Familiar flow for users who bookmark supabase.com - ✅ Supports domain-based automatic IdP routing - ⚠️ Requires configuring email domains -- ⚠️ More steps in the login process +- ⚠️ More steps in the sign-in process ## Choosing between flows @@ -65,7 +65,7 @@ With SP-initiated flow, users start at supabase.com, enter their email address, **Common scenarios:** - "Our team accesses all tools through Okta tiles" -- "We want the simplest possible login experience" +- "We want the simplest possible sign-in experience" - "We need separate Dev and Prod SAML apps under the same domain" - "Users should never need to remember supabase.com" @@ -81,7 +81,7 @@ With SP-initiated flow, users start at supabase.com, enter their email address, - "Some users bookmark supabase.com and expect to start there" - "We're transitioning from password auth to SSO" -- "Users need a consistent login page across all tools" +- "Users need a consistent sign-in page across all tools" - "We want domain-based automatic IdP selection" ### When to enable both flows @@ -94,7 +94,7 @@ You can enable both flows simultaneously to support different user preferences. - Gradual SSO migration with mixed authentication - Supporting both technical and non-technical users -## Configuring login flows +## Configuring sign-in flows ### Enabling IdP-initiated flow (default) @@ -133,13 +133,13 @@ To enable SP-initiated flow, you need to configure email domains: -Only users with email addresses matching your configured domains can use SP-initiated login. Users with other domains cannot sign in via SSO at supabase.com (but can still use IdP-initiated flow if you configure it in your IdP). +Only users with email addresses matching your configured domains can use SP-initiated sign-in. Users with other domains cannot sign in via SSO at supabase.com (but can still use IdP-initiated flow if you configure it in your IdP). ### Switching between flows -You can change login flow configuration at any time: +You can change sign-in flow configuration at any time: #### To switch from SP-initiated to IdP-only @@ -224,11 +224,11 @@ This is the recommended approach for enterprises with multiple environments. Con ### Can you use both flows simultaneously? -Yes! Enable SP-initiated login and configure domains. IdP-initiated flow continues to work automatically. +Yes! Enable SP-initiated sign-in and configure domains. IdP-initiated flow continues to work automatically. ### What happens when you don't configure domains? -Without domains, only IdP-initiated flow is available. Users cannot start their login at supabase.com. +Without domains, only IdP-initiated flow is available. Users cannot start their sign-in at supabase.com. ### Does the IdP require configuration? @@ -261,7 +261,7 @@ See our [SSO Testing and Best Practices](/docs/guides/platform/sso/testing-best- ## Next steps -- **Choose your login flow:** See [Choosing the Right Login Flow](/docs/guides/platform/sso/choosing-login-flow) +- **Choose your sign-in flow:** See [Choosing the Right Sign-in Flow](/docs/guides/platform/sso/choosing-login-flow) - **Configure your provider:** Follow our [provider-specific guides](/docs/guides/platform/sso#supported-providers) - **Test thoroughly:** Review [SSO Testing and Best Practices](/docs/guides/platform/sso/testing-best-practices) - **Enable auto-join:** Configure [auto-join settings](/docs/guides/platform/sso#key-configuration-options) for seamless onboarding diff --git a/apps/docs/content/guides/platform/sso/multiple-providers.mdx b/apps/docs/content/guides/platform/sso/multiple-providers.mdx index 7e5f49b3a532c..5e5d84adc6f49 100644 --- a/apps/docs/content/guides/platform/sso/multiple-providers.mdx +++ b/apps/docs/content/guides/platform/sso/multiple-providers.mdx @@ -25,7 +25,7 @@ The traditional challenge with multiple SAML apps is domain conflicts. With SP-i Configure each environment as IdP-initiated only (no domains). Users access each environment through different app tiles in your identity provider. -For technical details, see [the Understanding SSO Login Flows guide](/docs/guides/platform/sso/login-flows#multiple-saml-apps-per-domain). +For technical details, see [the Understanding SSO Sign-in Flows guide](/docs/guides/platform/sso/login-flows#multiple-saml-apps-per-domain). @@ -122,7 +122,7 @@ Assign appropriate users to each app. Users only see the tiles they're assigned Configure both organizations with SP-initiated enabled using the same domain: - Both organizations add `company.com` as a domain -- Users can log in via SP-initiated at supabase.com +- Users can sign in via SP-initiated at supabase.com - System routes based on org membership (first match wins) - Also provide IDP tiles for explicit routing @@ -190,7 +190,7 @@ All authenticate through the same central IDP but use different email domains. 1. Enable SSO with SP-initiated flow 2. Add all domains: `parent.com`, `subsidiary1.com`, `subsidiary2.com` 3. Configure single IDP metadata -4. Users with any matching domain can log in via supabase.com +4. Users with any matching domain can sign in via supabase.com #### Option B: Separate providers per subsidiary (IDP-initiated) @@ -542,5 +542,5 @@ If you currently have a single SSO provider and need to add more: - **Configure your IDP:** Follow your [provider-specific guide](/docs/guides/platform/sso#supported-providers) - **Test thoroughly:** Review [SSO Testing and Best Practices](/docs/guides/platform/sso/testing-best-practices) -- **Understand login flows:** Read [Understanding SSO Login Flows](/docs/guides/platform/sso/login-flows) -- **Choose the right flow:** See [Choosing the Right Login Flow](/docs/guides/platform/sso/choosing-login-flow) +- **Understand sign-in flows:** Read [Understanding SSO Sign-in Flows](/docs/guides/platform/sso/login-flows) +- **Choose the right flow:** See [Choosing the Right Sign-in Flow](/docs/guides/platform/sso/choosing-login-flow) diff --git a/apps/docs/content/guides/platform/sso/okta.mdx b/apps/docs/content/guides/platform/sso/okta.mdx index 8e51b7d7940e5..d0fba4986bb52 100644 --- a/apps/docs/content/guides/platform/sso/okta.mdx +++ b/apps/docs/content/guides/platform/sso/okta.mdx @@ -53,7 +53,7 @@ These settings let Supabase use SAML 2.0 properly with your Okta application. Ma ## Step 5: Fill out attribute statements [#add-attribute-statements] -Attribute Statements allow Supabase to get information about your Okta users on each login. +Attribute Statements allow Supabase to get information about your Okta users on each sign-in. **A `email` to `user.email` statement is required.** Other mappings shown below are optional and configurable depending on your Okta setup. If in doubt, replicate the same config as shown. You will use this mapping later in [Step 10](#dashboard-configure-attributes). @@ -122,15 +122,15 @@ If you did not customize your settings you may save some time by clicking the ** -**Recommended workflow:** Start with auto-join **disabled** to test your SSO configuration. Once SSO login is working correctly, enable auto-join if desired. +**Recommended workflow:** Start with auto-join **disabled** to test your SSO configuration. Once SSO sign-in is working correctly, enable auto-join if desired. -By default this setting is disabled, users logging in via SSO will not be added to your organization automatically. +By default this setting is disabled, users signing in via SSO will not be added to your organization automatically. ![Auto-join disabled](/docs/img/sso-dashboard-configure-autojoin-disabled.png) -Toggle this on if you want SSO-authenticated users to be **automatically added to your organization** when they log in via SSO. Auto-join applies on **every login**, not only on first signup - this makes it safe to test SSO before enabling this feature. +Toggle this on if you want SSO-authenticated users to be **automatically added to your organization** when they sign in via SSO. Auto-join applies on **every sign-in**, not only on first signup - this makes it safe to test SSO before enabling this feature. ![Auto-join enable](/docs/img/sso-dashboard-configure-autojoin-enabled.png) diff --git a/apps/docs/content/guides/platform/sso/testing-best-practices.mdx b/apps/docs/content/guides/platform/sso/testing-best-practices.mdx index 7877fc94f31b5..e68fa60acac09 100644 --- a/apps/docs/content/guides/platform/sso/testing-best-practices.mdx +++ b/apps/docs/content/guides/platform/sso/testing-best-practices.mdx @@ -10,19 +10,19 @@ After configuring your SSO provider, thorough testing is essential before rollin Before you begin testing, verify: - Organization has Team or Enterprise plan -- Login flow type decided (IdP-initiated, SP-initiated, or both) - see [Choosing a Login Flow](/docs/guides/platform/sso/choosing-login-flow) +- Sign-in flow type decided (IdP-initiated, SP-initiated, or both) - see [Choosing a Sign-in Flow](/docs/guides/platform/sso/choosing-login-flow) - Email domains identified (only required if using SP-initiated) - Auto-join settings and default role are decided - **At least one non-SSO owner account exists** (critical safety requirement) - Certificate expiration dates are documented (especially for Google Workspace) -## Testing login flows +## Testing sign-in flows -Before testing auto-join and other features, verify which login flows work for your SSO configuration. See [Understanding SSO Login Flows](/docs/guides/platform/sso/login-flows) for technical details. +Before testing auto-join and other features, verify which sign-in flows work for your SSO configuration. See [Understanding SSO Sign-in Flows](/docs/guides/platform/sso/login-flows) for technical details. -### Testing IdP-initiated login +### Testing IdP-initiated sign-in -IdP-initiated login is always available and doesn't require domain configuration. This should be your primary test. +IdP-initiated sign-in is always available and doesn't require domain configuration. This should be your primary test. **Test procedure:** @@ -33,8 +33,8 @@ IdP-initiated login is always available and doesn't require domain configuration 2. **Verify authentication:** - If already authenticated with IdP: Immediate redirect to Supabase - - If not authenticated: Complete IdP login flow, then redirect - - Check you're logged into the correct organization + - If not authenticated: Complete IdP sign-in flow, then redirect + - Check you're signed in to the correct organization - Verify user profile information is populated correctly 3. **Confirm success:** @@ -44,13 +44,13 @@ IdP-initiated login is always available and doesn't require domain configuration **Expected results:** -- ✅ Direct login from IdP with no intermediate steps +- ✅ Direct sign-in from IdP with no intermediate steps - ✅ Works regardless of domain configuration - ✅ User information properly mapped from IdP -### Testing SP-initiated login +### Testing SP-initiated sign-in -SP-initiated login requires domain configuration. Only test this if you've enabled SP-initiated flow. +SP-initiated sign-in requires domain configuration. Only test this if you've enabled SP-initiated flow. @@ -113,7 +113,7 @@ You've configured SSO with: 2. **Verify IdP-initiated works:** - Open IdP dashboard - Click Supabase app tile - - Should successfully log in + - Should successfully sign in - Verify correct organization access 3. **Confirm multi-environment pattern works (if applicable):** @@ -124,8 +124,8 @@ You've configured SSO with: **Expected results:** -- ✅ IdP-initiated login works perfectly -- ❌ SP-initiated login unavailable (expected) +- ✅ IdP-initiated sign-in works perfectly +- ❌ SP-initiated sign-in unavailable (expected) - ✅ Multiple environments accessible via different tiles - ✅ No domain conflicts between environments @@ -135,19 +135,19 @@ You've configured SSO with: -### Login flow verification checklist +### Sign-in flow verification checklist -- IdP-initiated login works from IdP dashboard -- SP-initiated login works (if domains configured) +- IdP-initiated sign-in works from IdP dashboard +- SP-initiated sign-in works (if domains configured) - SP-initiated properly blocked if no domains configured - Domain matching works correctly for SP-initiated - Non-matching domains show appropriate errors - Multiple environments route correctly (if using multiple providers) - Both flows work simultaneously (if both enabled) -## Testing SSO login flow +## Testing SSO sign-in flow -### Basic login test +### Basic sign-in test 1. **Navigate to the SSO sign-in page**: - Visit [Sign in with SSO](/dashboard/sign-in-sso) @@ -160,7 +160,7 @@ You've configured SSO with: 3. **Verify redirect to identity provider**: - You should be redirected to your identity provider (Okta, Azure AD, Google Workspace) - If already signed in to your IdP, you may be automatically redirected back - - If not signed in, complete the IdP login flow + - If not signed in, complete the IdP sign-in flow 4. **Confirm successful sign-in**: - You should be redirected back to Supabase dashboard @@ -180,7 +180,7 @@ Test with 2-3 additional users to verify: -**Recent improvement:** Auto-join now applies on EVERY login, not only on first signup. This resolves a common issue where org owners would test with auto-join disabled, enable it, then log in again expecting to auto-join. +**Recent improvement:** Auto-join now applies on EVERY sign-in, not only on first signup. This resolves a common issue where org owners would test with auto-join disabled, enable it, then sign in again expecting to auto-join. @@ -190,7 +190,7 @@ Test with 2-3 additional users to verify: - Navigate to [SSO settings](/dashboard/org/_/sso) - Ensure "Join organization on signup" is **disabled** - Configure your SSO provider - - Test basic SSO login (see above) + - Test basic SSO sign-in (see above) 2. **Enable auto-join after successful test**: - Return to [SSO settings](/dashboard/org/_/sso) @@ -199,7 +199,7 @@ Test with 2-3 additional users to verify: - Click "Save changes" 3. **Test auto-join with your account**: - - **Log out completely** from Supabase + - **Sign out completely** from Supabase - Sign in again via SSO - Verify you were automatically added to the organization - Check you received the correct default role @@ -217,7 +217,7 @@ Test with 2-3 additional users to verify: - Note: With IdP-initiated only, domain matching doesn't apply 6. **Test idempotency (prevents duplicate memberships)**: - - Log in again with an account that's already a member + - Sign in again with an account that's already a member - Verify no error occurs - Check members list - should be no duplicate entry - Confirm role hasn't changed unexpectedly @@ -253,7 +253,7 @@ Test with 2-3 additional users to verify: - Auto-join works when enabled - Users receive correct default role - Non-matching domains are excluded (if using SP-initiated with domains) -- Existing users auto-join on their next login (not only on new signups) +- Existing users auto-join on their next sign-in (not only on new signups) - Auto-join can be disabled and re-enabled as needed - Auto-join is idempotent (no duplicate memberships) - Auto-join works with IdP-initiated only (no domains) @@ -275,7 +275,7 @@ Test with 2-3 additional users to verify: - Select **"Require SSO"** option - Enter recipient email and select role - Send invitation - - Recipient must log in via SSO to accept + - Recipient must sign in via SSO to accept 2. **Create non-SSO invitation**: - Create a new invitation @@ -285,9 +285,9 @@ Test with 2-3 additional users to verify: 3. **Test SSO mismatch scenario**: - Create an SSO-required invitation - - Have recipient try to accept while logged in with a non-SSO account + - Have recipient try to accept while signed in with a non-SSO account - Error should display: "Invite token SSO provider does not match the one you are logged in with" - - Recipient should log out and sign in via SSO + - Recipient should sign out and sign in via SSO - Can then successfully accept the invitation ### Common invitation scenarios @@ -322,7 +322,7 @@ SSO accounts have specific restrictions to prevent accidental organization locko ### Testing SSO account deletion restrictions -1. **Log in with SSO account:** +1. **Sign in with SSO account:** - Authenticate via SSO (IdP or SP-initiated) - Navigate to [SSO settings](/dashboard/org/_/sso) - Verify you are an organization owner @@ -347,7 +347,7 @@ SSO accounts have specific restrictions to prevent accidental organization locko ### Testing with non-SSO owner account -1. **Log in with non-SSO owner:** +1. **Sign in with non-SSO owner:** - Use password or social auth account - Must be organization owner - Navigate to [SSO settings](/dashboard/org/_/sso) @@ -387,8 +387,8 @@ Based on customer pain points that previously required support intervention: **Solution:** -- Auto-join now applies on **every login**, not only on first signup -- To test: Enable auto-join, log out completely, log back in via SSO +- Auto-join now applies on **every sign-in**, not only on first signup +- To test: Enable auto-join, sign out completely, sign in again via SSO - If still not working, verify domain configuration matches user email exactly #### "Can't invite users with the right authentication type" @@ -407,17 +407,17 @@ Based on customer pain points that previously required support intervention: #### "Invitation acceptance shows 'SSO provider mismatch' error" -**Cause:** User is logged in with wrong authentication method for the invitation +**Cause:** User is signed in with wrong authentication method for the invitation **Solution:** -1. Check if invitation requires SSO or non-SSO login -2. Log out completely +1. Check if invitation requires SSO or non-SSO sign-in +2. Sign out completely 3. Sign in with the correct method (SSO or password/social) 4. Accept the invitation 5. Contact the person who sent the invitation if unsure about the type -#### "Deleted the SSO provider and now members can't log in" +#### "Deleted the SSO provider and now members can't sign in" **Recent safety improvements:** @@ -492,7 +492,7 @@ This behavior prevents "orphaned" SSO accounts that can no longer authenticate. 1. **Add non-SSO owner:** - Create or invite a non-SSO user (password or social login) - Promote to owner role - - **Critical:** Verify non-SSO owner can log in BEFORE deletion + - **Critical:** Verify non-SSO owner can sign in BEFORE deletion - Store credentials securely 2. **Document SSO members:** @@ -502,7 +502,7 @@ This behavior prevents "orphaned" SSO accounts that can no longer authenticate. **Test procedure:** 1. **Attempt deletion as non-SSO owner:** - - Log in with non-SSO owner account + - Sign in with non-SSO owner account - Navigate to [SSO settings](/dashboard/org/_/sso) - Delete SSO provider - Confirm deletion @@ -540,7 +540,7 @@ This behavior prevents "orphaned" SSO accounts that can no longer authenticate. - Document their roles 2. **Delete SSO provider:** - - Log in as non-SSO owner + - Sign in as non-SSO owner - Delete SSO provider - System may show member count being removed @@ -565,7 +565,7 @@ This behavior prevents "orphaned" SSO accounts that can no longer authenticate. 1. **Ensure non-SSO owner exists:** - Verify at least one non-SSO owner - - Test their login before deletion + - Test their sign-in before deletion 2. **Delete SSO provider:** - System allows deletion (non-SSO owner exists) @@ -596,7 +596,7 @@ This behavior prevents "orphaned" SSO accounts that can no longer authenticate. 1. **Create dedicated non-SSO owner account** - Use password authentication - - **Test that this account can log in** + - **Test that this account can sign in** - Store credentials in secure password manager - Verify owner permissions @@ -667,7 +667,7 @@ Common causes: **Solution:** 1. Create or convert an existing member to a non-SSO owner account -2. Verify the non-SSO owner can log in +2. Verify the non-SSO owner can sign in 3. Then proceed with SSO provider deletion **Why this is required:** Prevents complete organization lockout if SSO becomes unavailable @@ -682,7 +682,7 @@ Common causes: - System enforces this when deleting SSO provider - Create dedicated non-SSO owner **before** enabling SSO - Store credentials securely in a password manager -- Verify this account can log in before critical changes +- Verify this account can sign in before critical changes #### Monitor certificate expiration @@ -714,7 +714,7 @@ Common causes: 1. Create or verify non-SSO owner account exists 2. Configure SSO provider with auto-join **DISABLED** -3. Test SSO login with your own account +3. Test SSO sign-in with your own account 4. Verify attribute mappings are correct 5. Test with 2-3 additional users 6. Enable auto-join if desired @@ -757,7 +757,7 @@ Common causes: #### After SSO configuration changes -- Test login immediately +- Test sign-in immediately - Verify auto-join still works (if enabled) - Check that invitations are working - Confirm no users are locked out @@ -783,11 +783,11 @@ Common causes: Before rolling out SSO to your organization: -**Authentication & Login Flows:** +**Authentication & Sign-in Flows:** -- IdP-initiated login works from IdP dashboard -- SP-initiated login works (if domains configured) -- Appropriate login flow chosen for your use case +- IdP-initiated sign-in works from IdP dashboard +- SP-initiated sign-in works (if domains configured) +- Appropriate sign-in flow chosen for your use case - Domain configuration correct (or intentionally empty for IdP-only) - Multiple environments route correctly (if using multiple providers) @@ -795,7 +795,7 @@ Before rolling out SSO to your organization: - Auto-join adds users to correct organization (if enabled) - Auto-joined users receive correct default role -- Auto-join works on first login (not only on signup) +- Auto-join works on first sign-in (not only on signup) - Existing users auto-join when feature enabled - Auto-join is idempotent (no duplicate memberships) - Auto-join works with IdP-initiated (no domains required) @@ -811,7 +811,7 @@ Before rolling out SSO to your organization: **Safety & Access Controls:** - At least one non-SSO owner account exists -- Non-SSO owner account can log in successfully +- Non-SSO owner account can sign in successfully - Non-SSO credentials stored securely - SSO account deletion restrictions understood and tested - Safe deletion behavior verified (if tested) @@ -820,14 +820,14 @@ Before rolling out SSO to your organization: - Certificate expiration date documented with calendar reminders - Team notified of SSO availability -- Login instructions provided (IdP tile and/or supabase.com) +- Sign-in instructions provided (IdP tile and/or supabase.com) - Rollback plan documented - Support contact information available **Testing Completed:** - Tested with multiple user accounts -- Both login flows tested (if both enabled) +- Both sign-in flows tested (if both enabled) - Auto-join behavior verified - SSO account restrictions confirmed - Domain restrictions validated (if applicable) diff --git a/apps/docs/content/guides/queues/consuming-messages-with-edge-functions.mdx b/apps/docs/content/guides/queues/consuming-messages-with-edge-functions.mdx index 8a890895fe688..79b7e9d3e0986 100644 --- a/apps/docs/content/guides/queues/consuming-messages-with-edge-functions.mdx +++ b/apps/docs/content/guides/queues/consuming-messages-with-edge-functions.mdx @@ -15,6 +15,7 @@ This is a Supabase Edge Function that reads 5 messages off the queue, processes ```tsx import 'jsr:@supabase/functions-js/edge-runtime.d.ts' + import { createClient } from 'npm:@supabase/supabase-js@2' const supabaseUrl = 'supabaseURL' diff --git a/apps/docs/content/guides/security/platform-security.mdx b/apps/docs/content/guides/security/platform-security.mdx index e6ed64b34c023..f25f5e71220be 100644 --- a/apps/docs/content/guides/security/platform-security.mdx +++ b/apps/docs/content/guides/security/platform-security.mdx @@ -25,7 +25,7 @@ For configuration information, see [Enforce MFA on Organization](/docs/guides/pl ### SSO for organizations -Supabase offers single sign-on (SSO) as a login option to provide additional account security for your team. This allows company administrators to enforce the use of an identity provider when logging into Supabase. +Supabase offers single sign-on (SSO) as a sign-in option to provide additional account security for your team. This allows company administrators to enforce the use of an identity provider when signing in to Supabase. For configuration information, see [Enable SSO for Your Organization](/docs/guides/platform/sso). diff --git a/apps/docs/content/guides/self-hosting/docker.mdx b/apps/docs/content/guides/self-hosting/docker.mdx index 6b17aced1e484..ca849c63247ea 100644 --- a/apps/docs/content/guides/self-hosting/docker.mdx +++ b/apps/docs/content/guides/self-hosting/docker.mdx @@ -534,11 +534,11 @@ JWT_SECRET=${JWT_SECRET} ### Configuring social login (OAuth) providers -See the [Configure Social Login (OAuth) Providers](/docs/guides/self-hosting/self-hosted-oauth) guide for setup instructions. +See the [Configure social login (OAuth) Providers](/docs/guides/self-hosting/self-hosted-oauth) guide for setup instructions. -### Configuring phone login, SMS, and MFA +### Configuring phone sign-in, SMS, and MFA -See the [Configure Phone Login & MFA](/docs/guides/self-hosting/self-hosted-phone-mfa) guide for SMS provider setup, OTP settings, and multi-factor authentication configuration. +See the [Configure Phone sign-in & MFA](/docs/guides/self-hosting/self-hosted-phone-mfa) guide for SMS provider setup, OTP settings, and multi-factor authentication configuration. ### Configuring an email server diff --git a/apps/docs/content/guides/self-hosting/self-hosted-oauth.mdx b/apps/docs/content/guides/self-hosting/self-hosted-oauth.mdx index 331c94c5f1339..66e4872deb9c6 100644 --- a/apps/docs/content/guides/self-hosting/self-hosted-oauth.mdx +++ b/apps/docs/content/guides/self-hosting/self-hosted-oauth.mdx @@ -1,5 +1,5 @@ --- -title: 'Configure Social Login (OAuth) Providers' +title: 'Configure social login (OAuth) providers' description: 'Set up social login (OAuth/OIDC) providers for self-hosted Supabase with Docker.' subtitle: 'Set up social login (OAuth/OIDC) providers for self-hosted Supabase with Docker.' --- @@ -286,7 +286,7 @@ auth: -`KEYCLOAK_URL` is **required**. It must be the full realm URL (e.g., `https://keycloak.example.com/realms/myrealm`). The Auth service uses this to discover the OIDC endpoints (`.well-known/openid-configuration`). Without it, Keycloak login will not work. +`KEYCLOAK_URL` is **required**. It must be the full realm URL (e.g., `https://keycloak.example.com/realms/myrealm`). The Auth service uses this to discover the OIDC endpoints (`.well-known/openid-configuration`). Without it, Keycloak sign-in will not work. @@ -298,28 +298,28 @@ auth: Supabase Auth supports the following OAuth providers: -| Provider | Env prefix | Additional variables | Docs | -| ----------------- | ---------------- | ------------------------------- | --------------------------------------------------------------------- | -| Apple | `APPLE_` | - | [Login with Apple](/docs/guides/auth/social-login/auth-apple) | -| Azure (Microsoft) | `AZURE_` | `URL` (tenant URL) | [Login with Azure](/docs/guides/auth/social-login/auth-azure) | -| Bitbucket | `BITBUCKET_` | - | [Login with Bitbucket](/docs/guides/auth/social-login/auth-bitbucket) | -| Discord | `DISCORD_` | - | [Login with Discord](/docs/guides/auth/social-login/auth-discord) | -| Facebook | `FACEBOOK_` | - | [Login with Facebook](/docs/guides/auth/social-login/auth-facebook) | -| Figma | `FIGMA_` | - | [Login with Figma](/docs/guides/auth/social-login/auth-figma) | -| GitHub | `GITHUB_` | `URL` (for GitHub Enterprise) | [Login with GitHub](/docs/guides/auth/social-login/auth-github) | -| GitLab | `GITLAB_` | `URL` (for self-hosted GitLab) | [Login with GitLab](/docs/guides/auth/social-login/auth-gitlab) | -| Google | `GOOGLE_` | - | [Login with Google](/docs/guides/auth/social-login/auth-google) | -| Kakao | `KAKAO_` | - | [Login with Kakao](/docs/guides/auth/social-login/auth-kakao) | -| Keycloak (OIDC) | `KEYCLOAK_` | `URL` (realm URL, **required**) | [Login with Keycloak](/docs/guides/auth/social-login/auth-keycloak) | -| LinkedIn (OIDC) | `LINKEDIN_OIDC_` | - | [Login with LinkedIn](/docs/guides/auth/social-login/auth-linkedin) | -| Notion | `NOTION_` | - | [Login with Notion](/docs/guides/auth/social-login/auth-notion) | -| Slack (OIDC) | `SLACK_OIDC_` | - | [Login with Slack](/docs/guides/auth/social-login/auth-slack) | -| Snapchat | `SNAPCHAT_` | - | - | -| Spotify | `SPOTIFY_` | - | [Login with Spotify](/docs/guides/auth/social-login/auth-spotify) | -| Twitch | `TWITCH_` | - | [Login with Twitch](/docs/guides/auth/social-login/auth-twitch) | -| Twitter | `TWITTER_` | - | [Login with Twitter](/docs/guides/auth/social-login/auth-twitter) | -| WorkOS | `WORKOS_` | - | [Login with WorkOS](/docs/guides/auth/social-login/auth-workos) | -| Zoom | `ZOOM_` | - | [Login with Zoom](/docs/guides/auth/social-login/auth-zoom) | +| Provider | Env prefix | Additional variables | Docs | +| ----------------- | ---------------- | ------------------------------- | ----------------------------------------------------------------------- | +| Apple | `APPLE_` | - | [Sign in with Apple](/docs/guides/auth/social-login/auth-apple) | +| Azure (Microsoft) | `AZURE_` | `URL` (tenant URL) | [Sign in with Azure](/docs/guides/auth/social-login/auth-azure) | +| Bitbucket | `BITBUCKET_` | - | [Sign in with Bitbucket](/docs/guides/auth/social-login/auth-bitbucket) | +| Discord | `DISCORD_` | - | [Sign in with Discord](/docs/guides/auth/social-login/auth-discord) | +| Facebook | `FACEBOOK_` | - | [Sign in with Facebook](/docs/guides/auth/social-login/auth-facebook) | +| Figma | `FIGMA_` | - | [Sign in with Figma](/docs/guides/auth/social-login/auth-figma) | +| GitHub | `GITHUB_` | `URL` (for GitHub Enterprise) | [Sign in with GitHub](/docs/guides/auth/social-login/auth-github) | +| GitLab | `GITLAB_` | `URL` (for self-hosted GitLab) | [Sign in with GitLab](/docs/guides/auth/social-login/auth-gitlab) | +| Google | `GOOGLE_` | - | [Sign in with Google](/docs/guides/auth/social-login/auth-google) | +| Kakao | `KAKAO_` | - | [Sign in with Kakao](/docs/guides/auth/social-login/auth-kakao) | +| Keycloak (OIDC) | `KEYCLOAK_` | `URL` (realm URL, **required**) | [Sign in with Keycloak](/docs/guides/auth/social-login/auth-keycloak) | +| LinkedIn (OIDC) | `LINKEDIN_OIDC_` | - | [Sign in with LinkedIn](/docs/guides/auth/social-login/auth-linkedin) | +| Notion | `NOTION_` | - | [Sign in with Notion](/docs/guides/auth/social-login/auth-notion) | +| Slack (OIDC) | `SLACK_OIDC_` | - | [Sign in with Slack](/docs/guides/auth/social-login/auth-slack) | +| Snapchat | `SNAPCHAT_` | - | - | +| Spotify | `SPOTIFY_` | - | [Sign in with Spotify](/docs/guides/auth/social-login/auth-spotify) | +| Twitch | `TWITCH_` | - | [Sign in with Twitch](/docs/guides/auth/social-login/auth-twitch) | +| Twitter | `TWITTER_` | - | [Sign in with Twitter](/docs/guides/auth/social-login/auth-twitter) | +| WorkOS | `WORKOS_` | - | [Sign in with WorkOS](/docs/guides/auth/social-login/auth-workos) | +| Zoom | `ZOOM_` | - | [Sign in with Zoom](/docs/guides/auth/social-login/auth-zoom) | For each provider, you need at minimum `ENABLED`, `CLIENT_ID`, `SECRET`, and `REDIRECT_URI` in `.env` and `docker-compose.yml`. @@ -329,7 +329,7 @@ For each provider, you need at minimum `ENABLED`, `CLIENT_ID`, `SECRET`, and `RE -## Test the login flow +## Test the sign-in flow You can test OAuth with the following minimal HTML page: @@ -378,7 +378,7 @@ You can test OAuth with the following minimal HTML page: ``` -For detailed client-side integration, see [Social Login](/docs/guides/auth/social-login). +For detailed client-side integration, see [social login](/docs/guides/auth/social-login). ## Troubleshooting @@ -400,9 +400,9 @@ auth: Run `sh run.sh printenv auth | grep GOTRUE_EXTERNAL` to verify the variables are reaching the container. -### Site URL or redirect URL errors after login +### Site URL or redirect URL errors after sign-in -After a successful OAuth login, the Auth service redirects to `SITE_URL` or a URL from `ADDITIONAL_REDIRECT_URLS`. Ensure: +After a successful OAuth sign-in, the Auth service redirects to `SITE_URL` or a URL from `ADDITIONAL_REDIRECT_URLS`. Ensure: - `SITE_URL` in `.env` is set to your **application's URL** - If your app uses a different redirect URL, add it to `ADDITIONAL_REDIRECT_URLS` (comma-separated) diff --git a/apps/docs/content/guides/self-hosting/self-hosted-phone-mfa.mdx b/apps/docs/content/guides/self-hosting/self-hosted-phone-mfa.mdx index 99eaa048419c6..071b14df568a5 100644 --- a/apps/docs/content/guides/self-hosting/self-hosted-phone-mfa.mdx +++ b/apps/docs/content/guides/self-hosting/self-hosted-phone-mfa.mdx @@ -1,12 +1,12 @@ --- -title: 'Configure Phone Login & MFA' -description: 'Set up phone login SMS providers, OTP settings, and multi-factor authentication for self-hosted Supabase with Docker.' -subtitle: 'Set up phone login SMS providers, OTP settings, and multi-factor authentication for self-hosted Supabase with Docker.' +title: 'Configure Phone sign-in & MFA' +description: 'Set up phone sign-in SMS providers, OTP settings, and multi-factor authentication for self-hosted Supabase with Docker.' +subtitle: 'Set up phone sign-in SMS providers, OTP settings, and multi-factor authentication for self-hosted Supabase with Docker.' --- -This guide covers the **server-side configuration** for phone login and multi-factor authentication (MFA) on a self-hosted Supabase instance running with Docker Compose. +This guide covers the **server-side configuration** for phone sign-in and multi-factor authentication (MFA) on a self-hosted Supabase instance running with Docker Compose. -For client-side implementation, see [Phone Login](/docs/guides/auth/phone-login) and [Multi-Factor Authentication](/docs/guides/auth/auth-mfa). +For client-side implementation, see [Phone sign-in](/docs/guides/auth/phone-login) and [Multi-Factor Authentication](/docs/guides/auth/auth-mfa). ## Before you begin @@ -153,7 +153,7 @@ MFA_TOTP_VERIFY_ENABLED=false ### Phone MFA -Phone MFA is **disabled by default** (opt-in). It uses the same SMS provider configuration as phone login. +Phone MFA is **disabled by default** (opt-in). It uses the same SMS provider configuration as phone sign-in. To enable: diff --git a/apps/docs/content/guides/self-hosting/self-hosted-saml-sso.mdx b/apps/docs/content/guides/self-hosting/self-hosted-saml-sso.mdx index e0514267ef99d..15054f368e0c1 100644 --- a/apps/docs/content/guides/self-hosting/self-hosted-saml-sso.mdx +++ b/apps/docs/content/guides/self-hosting/self-hosted-saml-sso.mdx @@ -32,7 +32,7 @@ SAML SSO is configured in two layers: 1. **Global SAML enable (environment variables)** - a small set of env vars that enable the SAML engine and provide a signing key. These go in `.env` and `docker-compose.yml`. 2. **Per-IdP configuration (admin API)** - individual Identity Providers are registered, updated, and deleted at runtime via the Auth admin API. No restart is needed when adding or removing providers. -The login flow works as follows: +The sign-in flow works as follows: 1. Your app calls `POST /auth/v1/sso` with a domain or provider_id 2. Auth generates a SAML `AuthnRequest` and returns a redirect URL to the IdP @@ -506,15 +506,15 @@ Both return `{ "url": "https://idp.example.com/sso?SAMLRequest=..." }`. ### Domain-based vs provider-based lookup -| Method | Use case | -| ------------ | --------------------------------------------------------------------------------------------------------------------------------------- | -| `domain` | Extract the domain from the user's email and let Auth find the right IdP. Best for login forms where the user enters their email first. | -| `providerId` | Use when you know the exact provider - for example, a dedicated "Sign in with Okta" button. | +| Method | Use case | +| ------------ | ----------------------------------------------------------------------------------------------------------------------------------------- | +| `domain` | Extract the domain from the user's email and let Auth find the right IdP. Best for sign-in forms where the user enters their email first. | +| `providerId` | Use when you know the exact provider - for example, a dedicated "Sign in with Okta" button. | -## Test the login flow +## Test the sign-in flow -1. Open your application and trigger SSO login (or use the curl command above) -2. You should be redirected to your IdP's login page +1. Open your application and trigger SSO sign-in (or use the curl command above) +2. You should be redirected to your IdP's sign-in page 3. After authenticating, the IdP posts back to the ACS endpoint 4. Auth processes the assertion and redirects you back to your `SITE_URL` (or `redirect_to` URL) with session tokens diff --git a/apps/docs/content/guides/storage/management/copy-move-objects.mdx b/apps/docs/content/guides/storage/management/copy-move-objects.mdx index 844bdbf6d5293..1725badee7ee3 100644 --- a/apps/docs/content/guides/storage/management/copy-move-objects.mdx +++ b/apps/docs/content/guides/storage/management/copy-move-objects.mdx @@ -18,6 +18,7 @@ To copy an object within the same bucket, use the `copy` method. ```javascript import { createClient } from '@supabase/supabase-js' + const supabase = createClient('your_project_url', 'your_supabase_api_key') // ---cut--- @@ -30,6 +31,7 @@ To copy an object across buckets, use the `copy` method and specify the destinat ```javascript import { createClient } from '@supabase/supabase-js' + const supabase = createClient('your_project_url', 'your_supabase_api_key') // ---cut--- @@ -50,6 +52,7 @@ To move an object within the same bucket, you can use the `move` method. ```javascript import { createClient } from '@supabase/supabase-js' + const supabase = createClient('your_project_url', 'your_supabase_api_key') // ---cut--- @@ -64,6 +67,7 @@ To move an object across buckets, use the `move` method and specify the destinat ```javascript import { createClient } from '@supabase/supabase-js' + const supabase = createClient('your_project_url', 'your_supabase_api_key') // ---cut--- diff --git a/apps/docs/content/guides/storage/management/delete-objects.mdx b/apps/docs/content/guides/storage/management/delete-objects.mdx index f3719ab5785d3..03c102d3628e3 100644 --- a/apps/docs/content/guides/storage/management/delete-objects.mdx +++ b/apps/docs/content/guides/storage/management/delete-objects.mdx @@ -20,6 +20,7 @@ To delete one or more objects, use the `remove` method. ```javascript import { createClient } from '@supabase/supabase-js' + const supabase = createClient('your_project_url', 'your_supabase_api_key') // ---cut--- diff --git a/apps/docs/content/guides/storage/serving/downloads.mdx b/apps/docs/content/guides/storage/serving/downloads.mdx index fe267d3711134..23235fb6c1f6f 100644 --- a/apps/docs/content/guides/storage/serving/downloads.mdx +++ b/apps/docs/content/guides/storage/serving/downloads.mdx @@ -21,6 +21,7 @@ You can also use the Supabase SDK `getPublicUrl` to generate this URL for you ```js import { createClient } from '@supabase/supabase-js' + const supabase = createClient('your_project_url', 'your_supabase_api_key') // ---cut--- @@ -50,6 +51,7 @@ When using the SDK's `download()` method, you can pass additional query paramete ```js import { createClient } from '@supabase/supabase-js' + const supabase = createClient('your_project_url', 'your_supabase_api_key') // ---cut--- @@ -130,6 +132,7 @@ You can sign a time-limited URL that you can share to your users by invoking the ```js import { createClient } from '@supabase/supabase-js' + const supabase = createClient('your_project_url', 'your_supabase_api_key') // ---cut--- diff --git a/apps/docs/spec/cli_v1_commands--old.yaml b/apps/docs/spec/cli_v1_commands--old.yaml index f3671ceb1aea0..509df82773393 100644 --- a/apps/docs/spec/cli_v1_commands--old.yaml +++ b/apps/docs/spec/cli_v1_commands--old.yaml @@ -172,7 +172,7 @@ commands: - id: supabase-projects-list title: supabase projects list summary: List all Supabase projects - description: List all Supabase projects the logged-in user can access. + description: List all Supabase projects the signed-in user can access. tags: [] links: [] usage: |- @@ -218,7 +218,7 @@ commands: - id: supabase-orgs-list title: supabase orgs list summary: List all organizations - description: List all organizations the logged-in user belongs. + description: List all organizations the signed-in user belongs. tags: [] links: [] usage: |- diff --git a/apps/docs/spec/cli_v1_commands.yaml b/apps/docs/spec/cli_v1_commands.yaml index ab1ba004251bc..69af4b60ae33c 100644 --- a/apps/docs/spec/cli_v1_commands.yaml +++ b/apps/docs/spec/cli_v1_commands.yaml @@ -730,7 +730,7 @@ commands: title: supabase sso remove summary: Remove an existing SSO identity provider description: | - Remove a connection to an already added SSO identity provider. Removing the provider will prevent existing users from logging in. Please treat this command with care. + Remove a connection to an already added SSO identity provider. Removing the provider will prevent existing users from signing in. Please treat this command with care. examples: - id: basic-usage name: Remove a provider @@ -1085,7 +1085,7 @@ commands: - id: supabase-projects-list title: supabase projects list summary: List all Supabase projects - description: List all Supabase projects the logged-in user can access. + description: List all Supabase projects the signed-in user can access. tags: [] links: [] usage: supabase projects list @@ -1346,7 +1346,7 @@ commands: - id: supabase-orgs-list title: supabase orgs list summary: List all organizations - description: List all organizations the logged-in user belongs. + description: List all organizations the signed-in user belongs to. tags: [] links: [] usage: supabase orgs list @@ -1355,7 +1355,7 @@ commands: - id: supabase-orgs-create title: supabase orgs create summary: Create an organization - description: Create an organization for the logged-in user. + description: Create an organization for the signed-in user. tags: [] links: [] usage: supabase orgs create @@ -1794,7 +1794,7 @@ commands: summary: Authenticate using an access token description: |2 - Connect the Supabase CLI to your Supabase account by logging in with your [personal access token](https://supabase.com/dashboard/account/tokens). + Connect the Supabase CLI to your Supabase account by signing in with your [personal access token](https://supabase.com/dashboard/account/tokens). Your access token is stored securely in [native credentials storage](https://github.com/zalando/go-keyring#dependencies). If native credentials storage is unavailable, it will be written to a plain text file at `~/.supabase/access-token`. diff --git a/apps/docs/spec/cli_v1_config.yaml b/apps/docs/spec/cli_v1_config.yaml index 1bf0a040dd72b..6c0a612d95a36 100644 --- a/apps/docs/spec/cli_v1_config.yaml +++ b/apps/docs/spec/cli_v1_config.yaml @@ -1489,7 +1489,7 @@ parameters: required: false default: '' description: | - Force log out after the specified duration. Sample values include: '50m', '20h'. + Force sign out after the specified duration. Sample values include: '50m', '20h'. links: - name: 'Auth Sessions' link: 'https://supabase.com/docs/guides/auth/sessions' @@ -1500,7 +1500,7 @@ parameters: required: false default: '' description: | - Force log out if the user has been inactive longer than the specified duration. Sample values include: '50m', '20h'. + Force sign out if the user has been inactive longer than the specified duration. Sample values include: '50m', '20h'. links: - name: 'Auth Sessions' link: 'https://supabase.com/docs/guides/auth/sessions' diff --git a/apps/docs/spec/reference/dart/v2/partials/introduction.mdx b/apps/docs/spec/reference/dart/v2/partials/introduction.mdx index a1b21c70f2b60..497b8f6d07d2f 100644 --- a/apps/docs/spec/reference/dart/v2/partials/introduction.mdx +++ b/apps/docs/spec/reference/dart/v2/partials/introduction.mdx @@ -2,6 +2,6 @@ title: 'Introduction' --- -This reference documents every object and method available in Supabase's Flutter library, [supabase-flutter](https://pub.dev/packages/supabase_flutter). You can use supabase-flutter to interact with your Postgres database, listen to database changes, invoke Deno Edge Functions, build login and user management functionality, and manage large files. +This reference documents every object and method available in Supabase's Flutter library, [supabase-flutter](https://pub.dev/packages/supabase_flutter). You can use supabase-flutter to interact with your Postgres database, listen to database changes, invoke Deno Edge Functions, build sign-in and user management functionality, and manage large files. We also provide a [supabase](https://pub.dev/packages/supabase) package for non-Flutter projects. diff --git a/apps/docs/spec/reference/javascript/v2/partials/introduction.mdx b/apps/docs/spec/reference/javascript/v2/partials/introduction.mdx index 2de91f081eba8..b1f0825fe2d23 100644 --- a/apps/docs/spec/reference/javascript/v2/partials/introduction.mdx +++ b/apps/docs/spec/reference/javascript/v2/partials/introduction.mdx @@ -3,7 +3,7 @@ id: introduction title: Introduction --- -This reference documents every object and method available in Supabase's isomorphic JavaScript library, `supabase-js`. You can use `supabase-js` to interact with your Postgres database, listen to database changes, invoke Deno Edge Functions, build login and user management functionality, and manage large files. +This reference documents every object and method available in Supabase's isomorphic JavaScript library, `supabase-js`. You can use `supabase-js` to interact with your Postgres database, listen to database changes, invoke Deno Edge Functions, build sign-in and user management functionality, and manage large files. To convert SQL queries to `supabase-js` calls, use the [SQL to REST API translator](/docs/guides/api/sql-to-rest). diff --git a/apps/docs/spec/supabase_csharp_v0.yml b/apps/docs/spec/supabase_csharp_v0.yml index 09134ade3ae4c..03ea3bd09509f 100644 --- a/apps/docs/spec/supabase_csharp_v0.yml +++ b/apps/docs/spec/supabase_csharp_v0.yml @@ -119,7 +119,7 @@ functions: description: | Creates a new user. notes: | - - By default, the user needs to verify their email address before logging in. To turn this off, disable **Confirm email** in [your project](https://supabase.com/dashboard/project/_/auth/providers). + - By default, the user needs to verify their email address before signing in. To turn this off, disable **Confirm email** in [your project](https://supabase.com/dashboard/project/_/auth/providers). - **Confirm email** determines if users need to confirm their email address after signing up. - If **Confirm email** is enabled, a `user` is returned but `session` is null. - If **Confirm email** is disabled, both a `user` and a `session` are returned. @@ -138,7 +138,7 @@ functions: - id: sign-in-with-password title: 'SignIn(email, password)' description: | - Log in an existing user using email or phone number with password. + Sign in an existing user using email or phone number with password. notes: | - Requires either an email and password or a phone number and password. examples: @@ -215,7 +215,7 @@ functions: - id: sign-out title: 'SignOut()' description: | - Signs out the current user, if there is a logged in user. + Signs out the current user, if there is a signed-in user. notes: | - In order to use the `SignOut()` method, the user needs to be signed in first. examples: @@ -254,9 +254,9 @@ functions: - id: get-user title: 'CurrentUser' description: | - Returns the user data, if there is a logged in user. + Returns the user data, if there is a signed-in user. examples: - - name: Get the logged in user + - name: Get the signed-in user isSpotlight: true code: | ```c# @@ -265,7 +265,7 @@ functions: - id: update-user title: 'UpdateUser()' description: | - Updates user data, if there is a logged in user. + Updates user data, if there is a signed-in user. notes: | - In order to use the `UpdateUser()` method, the user needs to be signed in first. - By Default, email updates sends a confirmation link to both the user's current and new email. diff --git a/apps/docs/spec/supabase_csharp_v1.yml b/apps/docs/spec/supabase_csharp_v1.yml index a5b868a0c6aff..dd5e3078e4dd4 100644 --- a/apps/docs/spec/supabase_csharp_v1.yml +++ b/apps/docs/spec/supabase_csharp_v1.yml @@ -116,7 +116,7 @@ functions: description: | Creates a new user. notes: | - - By default, the user needs to verify their email address before logging in. To turn this off, disable **Confirm email** in [your project](https://supabase.com/dashboard/project/_/auth/providers). + - By default, the user needs to verify their email address before signing in. To turn this off, disable **Confirm email** in [your project](https://supabase.com/dashboard/project/_/auth/providers). - **Confirm email** determines if users need to confirm their email address after signing up. - If **Confirm email** is enabled, a `user` is returned but `session` is null. - If **Confirm email** is disabled, both a `user` and a `session` are returned. @@ -135,7 +135,7 @@ functions: - id: sign-in-with-password title: 'SignIn(email, password)' description: | - Log in an existing user using email or phone number with password. + Sign in an existing user using email or phone number with password. notes: | - Requires either an email and password or a phone number and password. examples: @@ -212,7 +212,7 @@ functions: - id: sign-out title: 'SignOut()' description: | - Signs out the current user, if there is a logged in user. + Signs out the current user, if there is a signed-in user. notes: | - In order to use the `SignOut()` method, the user needs to be signed in first. examples: @@ -259,9 +259,9 @@ functions: - id: get-user title: 'CurrentUser' description: | - Returns the user data, if there is a logged in user. + Returns the user data, if there is a signed-in user. examples: - - name: Get the logged in user + - name: Get the signed-in user isSpotlight: true code: | ```c# @@ -270,7 +270,7 @@ functions: - id: update-user title: 'UpdateUser()' description: | - Updates user data, if there is a logged in user. + Updates user data, if there is a signed-in user. notes: | - In order to use the `UpdateUser()` method, the user needs to be signed in first. - By Default, email updates sends a confirmation link to both the user's current and new email. @@ -1558,7 +1558,7 @@ functions: - id: from-create-signed-upload-url description: | - Creates a signed URL that can be used to upload a file without requiring a logged-in user. This is useful for handing off uploads to an untrusted client. + Creates a signed URL that can be used to upload a file without requiring a signed-in user. This is useful for handing off uploads to an untrusted client. title: 'From().CreateUploadSignedUrl()' notes: | - Policy permissions required: diff --git a/apps/docs/spec/supabase_dart_v1.yml b/apps/docs/spec/supabase_dart_v1.yml index 709d4c1329473..2df29e6137128 100644 --- a/apps/docs/spec/supabase_dart_v1.yml +++ b/apps/docs/spec/supabase_dart_v1.yml @@ -56,7 +56,7 @@ functions: description: | Creates a new user. notes: | - - By default, the user needs to verify their email address before logging in. To turn this off, disable **Confirm email** in [your project](https://supabase.com/dashboard/project/_/auth/providers). + - By default, the user needs to verify their email address before signing in. To turn this off, disable **Confirm email** in [your project](https://supabase.com/dashboard/project/_/auth/providers). - **Confirm email** determines if users need to confirm their email address after signing up. - If **Confirm email** is enabled, a `user` is returned but `session` is null. - If **Confirm email** is disabled, both a `user` and a `session` are returned. @@ -107,7 +107,7 @@ functions: - id: sign-in-with-password title: 'signInWithPassword()' description: | - Log in an existing user using email or phone number with password. + Sign in an existing user using email or phone number with password. notes: | - Requires either an email and password or a phone number and password. examples: @@ -239,7 +239,7 @@ functions: - id: sign-out title: 'signOut()' description: | - Signs out the current user, if there is a logged in user. + Signs out the current user, if there is a signed-in user. notes: | - In order to use the `signOut()` method, the user needs to be signed in first. examples: @@ -297,9 +297,9 @@ functions: - id: get-user title: 'currentUser' description: | - Returns the user data, if there is a logged in user. + Returns the user data, if there is a signed-in user. examples: - - name: Get the logged in user + - name: Get the signed-in user isSpotlight: true code: | ```dart @@ -308,7 +308,7 @@ functions: - id: update-user title: 'updateUser()' description: | - Updates user data for a logged in user. + Updates user data for a signed-in user. notes: | - In order to use the `updateUser()` method, the user needs to be signed in first. - By Default, email updates sends a confirmation link to both the user's current and new email. @@ -750,7 +750,7 @@ functions: - id: parsing-custom-headers name: Parsing custom headers. description: | - Any `headers` will be passed through to the function. A common pattern is to pass a logged-in user's JWT token as an Authorization header. + Any `headers` will be passed through to the function. A common pattern is to pass a signed-in user's JWT token as an Authorization header. isSpotlight: true code: | ```dart diff --git a/apps/docs/spec/supabase_dart_v2.yml b/apps/docs/spec/supabase_dart_v2.yml index cb46b3999c742..8fba01c867319 100644 --- a/apps/docs/spec/supabase_dart_v2.yml +++ b/apps/docs/spec/supabase_dart_v2.yml @@ -121,7 +121,7 @@ functions: description: | Creates a new user. notes: | - - By default, the user needs to verify their email address before logging in. To turn this off, disable **Confirm email** in [your project](https://supabase.com/dashboard/project/_/auth/providers). + - By default, the user needs to verify their email address before signing in. To turn this off, disable **Confirm email** in [your project](https://supabase.com/dashboard/project/_/auth/providers). - **Confirm email** determines if users need to confirm their email address after signing up. - If **Confirm email** is enabled, a `user` is returned but `session` is null. - If **Confirm email** is disabled, both a `user` and a `session` are returned. @@ -363,7 +363,7 @@ functions: - id: sign-in-with-password title: 'signInWithPassword()' description: | - Log in an existing user using email or phone number with password. + Sign in an existing user using email or phone number with password. notes: | - Requires either an email and password or a phone number and password. params: @@ -977,7 +977,7 @@ functions: - id: register-passkey title: 'registerPasskey()' notes: | - Registers a new passkey (WebAuthn credential) for the signed in user. + Registers a new passkey (WebAuthn credential) for the signed-in user. - Available on `supabase_flutter` 2.15.0 and later as an extension on `GoTrueClient`. - Drives the full WebAuthn ceremony end to end: starts the registration with the Supabase server, calls the `authenticator` you supply to create a credential on the device, and verifies it with the server. - Requires a signed in (non-anonymous) user. If the user has verified MFA factors, the session has to be at `aal2` to manage passkeys. @@ -1011,7 +1011,7 @@ functions: - id: sign-out title: 'signOut()' description: | - Signs out the current user, if there is a logged in user. + Signs out the current user, if there is a signed-in user. notes: | - In order to use the `signOut()` method, the user needs to be signed in first. params: @@ -1233,9 +1233,9 @@ functions: - id: get-user title: 'currentUser' description: | - Returns the user data, if there is a logged in user. + Returns the user data, if there is a signed-in user. examples: - - name: Get the logged in user + - name: Get the signed-in user isSpotlight: true code: | ```dart @@ -1280,7 +1280,7 @@ functions: - id: update-user title: 'updateUser()' description: | - Updates user data for a logged in user. + Updates user data for a signed-in user. notes: | - In order to use the `updateUser()` method, the user needs to be signed in first. - By default, email updates sends a confirmation link to both the user's current and new email. @@ -2298,7 +2298,7 @@ functions: - id: passkey-list title: 'passkey.list()' notes: | - Returns the list of passkeys registered to the signed in user. + Returns the list of passkeys registered to the signed-in user. examples: - id: list-passkeys name: List the current user's passkeys @@ -2334,7 +2334,7 @@ functions: - id: passkey-delete title: 'passkey.delete()' notes: | - Deletes a passkey from the signed in user. + Deletes a passkey from the signed-in user. - If the user has verified MFA factors, the session has to be at `aal2` to manage passkeys. params: - name: passkeyId @@ -2354,7 +2354,7 @@ functions: - id: passkey-start-registration title: 'passkey.startRegistration()' notes: | - Starts the registration of a new passkey for the signed in user. + Starts the registration of a new passkey for the signed-in user. - Requires a signed in (non-anonymous) user. - Pass the returned `options` to the platform's passkey API to create the credential, then call [`passkey.verifyRegistration()`](/docs/reference/dart/auth-passkey-verifyregistration) with the result. - When the server omits `user.name`/`displayName` in the registration options, they are backfilled with `friendlyName` (or a generic `Passkey` default) before the platform ceremony. @@ -3269,7 +3269,7 @@ functions: - id: parsing-custom-headers name: Parsing custom headers. description: | - Any `headers` will be passed through to the function. A common pattern is to pass a logged-in user's JWT token as an Authorization header. + Any `headers` will be passed through to the function. A common pattern is to pass a signed-in user's JWT token as an Authorization header. isSpotlight: true code: | ```dart diff --git a/apps/docs/spec/supabase_js_v1.yml b/apps/docs/spec/supabase_js_v1.yml index 14946e1024664..d11dc4343e649 100644 --- a/apps/docs/spec/supabase_js_v1.yml +++ b/apps/docs/spec/supabase_js_v1.yml @@ -82,7 +82,7 @@ functions: title: 'signUp()' $ref: '@supabase/gotrue-js.GoTrueClient.signUp' notes: | - - By default, the user will need to verify their email address before logging in. If you would like to change this, you can disable "Email Confirmations" by going to Authentication -> Settings on [supabase.com/dashboard](https://supabase.com/dashboard) + - By default, the user will need to verify their email address before signing in. If you would like to change this, you can disable "Email Confirmations" by going to Authentication -> Settings on [supabase.com/dashboard](https://supabase.com/dashboard) - If "Email Confirmations" is turned on, a `user` is returned but `session` will be null - If "Email Confirmations" is turned off, both a `user` and a `session` will be returned - When the user confirms their email address, they will be redirected to localhost:3000 by default. To change this, you can go to Authentication -> Settings on [supabase.com/dashboard](https://supabase.com/dashboard) @@ -148,7 +148,7 @@ functions: - A user can sign up either via email or OAuth. - If you provide `email` without a `password`, the user will be sent a magic link. - The magic link's destination URL is determined by the SITE_URL config variable. To change this, you can go to Authentication -> Settings on [supabase.com/dashboard](https://supabase.com/dashboard) - - Specifying a `provider` will open the browser to the relevant login page. + - Specifying a `provider` will open the browser to the relevant sign-in page. examples: - id: sign-in-with-email-and-password name: Sign in with email and password @@ -192,10 +192,10 @@ functions: - id: sign-in-using-a-third-party-provider-with-redirect name: Sign in using a third-party provider with redirect description: | - Note that the `redirectTo` param is only relevant for OAuth logins, where the login flow is managed by - the Auth server. If you are using email/phone logins you should set up your own redirects (within the email/sms template). + Note that the `redirectTo` param is only relevant for OAuth sign-ins, where the sign-in flow is managed by + the Auth server. If you are using email/phone sign-ins you should set up your own redirects (within the email/sms template). - Sometimes you want to control where the user is redirected to after they are logged in. Supabase supports this for + Sometimes you want to control where the user is redirected to after they are signed in. Supabase supports this for any URL path on your website (the URL must either be on the same domain as your [Site URL](https://supabase.com/dashboard/project/_/auth/url-configuration) or match one of the Redirect URLs). See [redirect URLs and wildcards](/docs/guides/auth/redirect-urls#use-wildcards-in-redirect-urls) to add additional redirect URLs to your project. @@ -224,7 +224,7 @@ functions: - id: sign-in-with-refresh-token name: Sign in using a refresh token (e.g. in React Native). description: | - If you are completing a sign up or login in a React Native app you can pass the refresh token obtained from the provider to obtain a session. + If you are completing a sign up or sign-in in a React Native app you can pass the refresh token obtained from the provider to obtain a session. code: | ```js // An example using Expo's `AuthSession` @@ -273,7 +273,7 @@ functions: This method gets the user object from memory. examples: - id: - name: Get the logged in user + name: Get the signed-in user isSpotlight: true code: | ```js @@ -288,7 +288,7 @@ functions: To only send a confirmation link to the user's new email, disable **Secure email change** in your project's [email auth provider settings](https://supabase.com/dashboard/project/_/auth/providers). User metadata: It's generally better to store user data in a table within your public schema (i.e., `public.users`). - Use the `update()` method if you have data which rarely changes or is specific only to the logged in user. + Use the `update()` method if you have data which rarely changes or is specific only to the signed-in user. examples: - id: update-the-email-for-an-authenticated-user name: Update the email for an authenticated user @@ -737,7 +737,7 @@ functions: - id: passing-custom-headers name: Passing custom headers. description: | - You can pass custom headers to your Edge Function. Note: supabase-js automatically passes the `Authorization` header with the signed in user's JWT. + You can pass custom headers to your Edge Function. Note: supabase-js automatically passes the `Authorization` header with the signed-in user's JWT. isSpotlight: true code: | ```js diff --git a/apps/docs/spec/supabase_kt_v1.yml b/apps/docs/spec/supabase_kt_v1.yml index e8e869ea71ba2..4dd30b2de6eb7 100644 --- a/apps/docs/spec/supabase_kt_v1.yml +++ b/apps/docs/spec/supabase_kt_v1.yml @@ -29,7 +29,7 @@ functions: ### OAuth and OTP link verification [supabase-kt](https://github.com/supabase-community/supabase-kt) provides several platform implementations for OAuth and OTP link verification. \ - **On JVM**, it uses a HTTP Callback Server to receive the session data from a successful OAuth login. + **On JVM**, it uses a HTTP Callback Server to receive the session data from a successful OAuth sign-in. *Note: OTP link verification such as sign ups are not supported on JVM. You may have to send a verification token rather than a url in your E-Mail. To send the token, rather than a redirect url, you have to change `{{ .ConfirmationURL }}` in your sign up email to `{{ .Token }}`* @@ -63,7 +63,7 @@ functions: On Android: `supabase.handleDeeplinks(intent)` \ On IOS/macOS: `supabase.handleDeeplinks(url)` - Then you can just login using OAuth: + Then you can just sign in using OAuth: ```kotlin supabase.gotrue.loginWith(Google) ``` @@ -140,15 +140,15 @@ functions: **Desktop:** - `httpPort`: The port the web server is running on, when logging in with OAuth. Default: `0` (random port). + `httpPort`: The port the web server is running on, when signing in with OAuth. Default: `0` (random port). - `timeout`: The timeout for the web server, when logging in with OAuth. Default: `1.minutes`. + `timeout`: The timeout for the web server, when signing in with OAuth. Default: `1.minutes`. - `htmlTitle`: The title of the redirect page, when logging in with OAuth. Default: `"Supabase Auth"`. + `htmlTitle`: The title of the redirect page, when signing in with OAuth. Default: `"Supabase Auth"`. - `htmlText`: The text of the redirect page, when logging in with OAuth. Default: `"Logged in. You may continue in your app."`. + `htmlText`: The text of the redirect page, when signing in with OAuth. Default: `"Logged in. You may continue in your app."`. - `htmlIconUrl`: The icon of the redirect page, when logging in with OAuth. Default: `"https://supabase.com/brand-assets/supabase-logo-icon.png"`. + `htmlIconUrl`: The icon of the redirect page, when signing in with OAuth. Default: `"https://supabase.com/brand-assets/supabase-logo-icon.png"`. - id: configure-postgrest name: Configure PostgREST module code: | @@ -2094,10 +2094,10 @@ functions: $ref: '@supabase/gotrue-js.GoTrueClient.signUp' notes: | Creates a new user. - - By default, the user needs to verify their email address before logging in. To turn this off, disable **Confirm email** in [your project](https://supabase.com/dashboard/project/_/auth/providers). + - By default, the user needs to verify their email address before signing in. To turn this off, disable **Confirm email** in [your project](https://supabase.com/dashboard/project/_/auth/providers). - **Confirm email** determines if users need to confirm their email address after signing up. - - If **Confirm email** is enabled, the return value is the user and you won't be logged in automatically. - - If **Confirm email** is disabled, the return value is null and you will be logged in instead. + - If **Confirm email** is enabled, the return value is the user and you won't be signed in automatically. + - If **Confirm email** is disabled, the return value is null and you will be signed in instead. - When the user confirms their email address, they are redirected to the [`SITE_URL`](https://supabase.com/docs/guides/auth/redirect-urls) by default. You can modify your `SITE_URL` or add additional redirect URLs in [your project](https://supabase.com/dashboard/project/_/auth/url-configuration). - To learn how to handle OTP links & OAuth refer to [initializing](/docs/reference/kotlin/initializing) - If signUpWith() is called for an existing confirmed user: @@ -2345,7 +2345,7 @@ functions: title: 'Verify OTPs' $ref: '@supabase/gotrue-js.GoTrueClient.verifyOtp' notes: | - Log in a user given a User supplied OTP received via mobile. + Sign in a user given a User supplied OTP received via mobile. examples: - id: verify-email-otp(otp) name: Verify an Email OTP @@ -2447,7 +2447,7 @@ functions: - Should be used only when you require the most current user data. For faster results, `getCurrentSessionOrNull()?.user` is recommended. examples: - id: get-the-logged-in-user-with-the-current-existing-session - name: Get the logged in user with the current session + name: Get the signed-in user with the current session isSpotlight: true code: | ```kotlin @@ -2570,7 +2570,7 @@ functions: title: 'Send a password reset request' notes: | Sends a password reset request to the given email address. - - The password reset flow consist of 2 broad steps: (i) Allow the user to login via the password reset link; (ii) Update the user's password. + - The password reset flow consists of 2 broad steps: (i) Allow the user to sign in via the password reset link; (ii) Update the user's password. - The `sendRecoveryEmail()` only sends a password reset link to the user's email. To update the user's password, see [`modifyUser()`](/docs/reference/kotlin/auth-updateuser). - The user gets redirected back to your app, assuming you setup [OTP handling](/docs/reference/kotlin/initializing) @@ -2737,7 +2737,7 @@ functions: val enabledFlow = supabase.gotrue.mfa.isMfaEnabledFlow ``` - id: aal-enabled-for-current-session - name: Check whether the user is logged in using AAL2 + name: Check whether the user is signed in using AAL2 isSpotlight: true code: | ```kotlin diff --git a/apps/docs/spec/supabase_kt_v2.yml b/apps/docs/spec/supabase_kt_v2.yml index a42bb368f45ce..5681c7641f335 100644 --- a/apps/docs/spec/supabase_kt_v2.yml +++ b/apps/docs/spec/supabase_kt_v2.yml @@ -30,7 +30,7 @@ functions: [supabase-kt](https://github.com/supabase-community/supabase-kt) provides several platform implementations for OAuth and OTP link verification. - **On Desktop platforms (JVM, MacOS\*, Linux)**, it uses a HTTP Callback Server to receive the session data from a successful OAuth login. The success page can be customized via `AuthConfig#httpCallbackConfig` \ + **On Desktop platforms (JVM, MacOS\*, Linux)**, it uses a HTTP Callback Server to receive the session data from a successful OAuth sign-in. The success page can be customized via `AuthConfig#httpCallbackConfig` \ \* If no deeplinks are being used. *Note: OTP link verification such as sign ups are not supported on JVM. You may have to send a verification token rather than a url in your email. To send the token, rather than a redirect url, change `{{ .ConfirmationURL }}` in your sign up email to `{{ .Token }}`* @@ -66,7 +66,7 @@ functions: If you don't want a separate activity, just call this function at the top of your `onCreate` function in your MainActivity. \ On iOS/MacOS: `supabase.handleDeeplinks(url)` - Then you can log in using OAuth: + Then you can sign in using OAuth: ```kotlin supabase.auth.signInWith(Google) ``` @@ -182,15 +182,15 @@ functions: **Desktop:** - `httpPort`: The port the web server is running on, when logging in with OAuth. Default: `0` (random port). + `httpPort`: The port the web server is running on, when signing in with OAuth. Default: `0` (random port). - `timeout`: The timeout for the web server, when logging in with OAuth. Default: `1.minutes`. + `timeout`: The timeout for the web server, when signing in with OAuth. Default: `1.minutes`. - `htmlTitle`: The title of the redirect page, when logging in with OAuth. Default: `"Supabase Auth"`. + `htmlTitle`: The title of the redirect page, when signing in with OAuth. Default: `"Supabase Auth"`. - `htmlText`: The text of the redirect page, when logging in with OAuth. Default: `"Logged in. You may continue in your app."`. + `htmlText`: The text of the redirect page, when signing in with OAuth. Default: `"Logged in. You may continue in your app."`. - `htmlIconUrl`: The icon of the redirect page, when logging in with OAuth. Default: `"https://supabase.com/brand-assets/supabase-logo-icon.png"`. + `htmlIconUrl`: The icon of the redirect page, when signing in with OAuth. Default: `"https://supabase.com/brand-assets/supabase-logo-icon.png"`. - id: configure-postgrest name: Configure PostgREST module code: | @@ -2824,10 +2824,10 @@ functions: $ref: '@supabase/gotrue-js.GoTrueClient.signUp' notes: | Creates a new user. - - By default, the user needs to verify their email address before logging in. To turn this off, disable **Confirm email** in [your project](https://supabase.com/dashboard/project/_/auth/providers). + - By default, the user needs to verify their email address before signing in. To turn this off, disable **Confirm email** in [your project](https://supabase.com/dashboard/project/_/auth/providers). - **Confirm email** determines if users need to confirm their email address after signing up. - - If **Confirm email** is enabled, the return value is the user and you won't be logged in automatically. - - If **Confirm email** is disabled, the return value is null and you will be logged in instead. + - If **Confirm email** is enabled, the return value is the user and you won't be signed in automatically. + - If **Confirm email** is disabled, the return value is null and you will be signed in instead. - When the user confirms their email address, they are redirected to the [`SITE_URL`](https://supabase.com/docs/guides/auth/redirect-urls) by default. You can modify your `SITE_URL` or add additional redirect URLs in [your project](https://supabase.com/dashboard/project/_/auth/url-configuration). - To learn how to handle OTP links & OAuth refer to [initializing](/docs/reference/kotlin/initializing) - If signUpWith() is called for an existing confirmed user: @@ -3423,7 +3423,7 @@ functions: description: The JWT token. examples: - id: get-the-logged-in-user-with-the-current-existing-session - name: Get the logged in user with the current session + name: Get the signed-in user with the current session isSpotlight: true code: | ```kotlin @@ -3696,7 +3696,7 @@ functions: title: 'Send a password reset request' notes: | Sends a password reset request to the given email address. - - The password reset flow consist of 2 broad steps: (i) Allow the user to login via the password reset link; (ii) Update the user's password. + - The password reset flow consists of 2 broad steps: (i) Allow the user to sign in via the password reset link; (ii) Update the user's password. - The `resetPasswordForEmail()` only sends a password reset link to the user's email. To update the user's password, see [`updateUser()`](/docs/reference/kotlin/auth-updateuser). - The user gets redirected back to your app, assuming you setup [OTP handling](/docs/reference/kotlin/initializing) @@ -3962,7 +3962,7 @@ functions: val statusFlow = supabase.auth.mfa.statusFlow ``` - id: aal-enabled-for-current-session - name: Check whether the user is logged in using AAL2 + name: Check whether the user is signed in using AAL2 isSpotlight: true code: | ```kotlin diff --git a/apps/docs/spec/supabase_kt_v3.yml b/apps/docs/spec/supabase_kt_v3.yml index be7d643535dd4..c5dd7db3a28af 100644 --- a/apps/docs/spec/supabase_kt_v3.yml +++ b/apps/docs/spec/supabase_kt_v3.yml @@ -35,7 +35,7 @@ functions: The following will explain how each target handles OAuth and OTP link verification, if supported. - **On Desktop platforms (JVM, MacOS\*, Linux, Windows)**, it uses a HTTP Callback Server to receive the session data from a successful OAuth login. The success page can be customized via `AuthConfig#httpCallbackConfig` \ + **On Desktop platforms (JVM, MacOS\*, Linux, Windows)**, it uses a HTTP Callback Server to receive the session data from a successful OAuth sign-in. The success page can be customized via `AuthConfig#httpCallbackConfig` \ \* If no deeplinks are being used. This works as-is, by default. *Note: OTP link verification such as sign ups are not supported on JVM. You may have to send a verification token rather than a url in your email. To send the token, rather than a redirect url, change `{{ .ConfirmationURL }}` in your sign up email to `{{ .Token }}`* @@ -71,7 +71,7 @@ functions: If you don't want a separate activity, just call this function at the top of your `onCreate` function in your MainActivity. \ On iOS/MacOS: `supabase.handleDeeplinks(url)` - Then you can log in using OAuth: + Then you can sign in using OAuth: ```kotlin supabase.auth.signInWith(Google) ``` @@ -187,15 +187,15 @@ functions: **Desktop:** - `httpPort`: The port the web server is running on, when logging in with OAuth. Default: `0` (random port). + `httpPort`: The port the web server is running on, when signing in with OAuth. Default: `0` (random port). - `timeout`: The timeout for the web server, when logging in with OAuth. Default: `1.minutes`. + `timeout`: The timeout for the web server, when signing in with OAuth. Default: `1.minutes`. - `htmlTitle`: The title of the redirect page, when logging in with OAuth. Default: `"Supabase Auth"`. + `htmlTitle`: The title of the redirect page, when signing in with OAuth. Default: `"Supabase Auth"`. - `htmlText`: The text of the redirect page, when logging in with OAuth. Default: `"Logged in. You may continue in your app."`. + `htmlText`: The text of the redirect page, when signing in with OAuth. Default: `"Logged in. You may continue in your app."`. - `htmlIconUrl`: The icon of the redirect page, when logging in with OAuth. Default: `"https://supabase.com/brand-assets/supabase-logo-icon.png"`. + `htmlIconUrl`: The icon of the redirect page, when signing in with OAuth. Default: `"https://supabase.com/brand-assets/supabase-logo-icon.png"`. - id: configure-postgrest name: Configure PostgREST module code: | @@ -3010,10 +3010,10 @@ functions: $ref: '@supabase/gotrue-js.GoTrueClient.signUp' notes: | Creates a new user. - - By default, the user needs to verify their email address before logging in. To turn this off, disable **Confirm email** in [your project](https://supabase.com/dashboard/project/_/auth/providers). + - By default, the user needs to verify their email address before signing in. To turn this off, disable **Confirm email** in [your project](https://supabase.com/dashboard/project/_/auth/providers). - **Confirm email** determines if users need to confirm their email address after signing up. - - If **Confirm email** is enabled, the return value is the user and you won't be logged in automatically. - - If **Confirm email** is disabled, the return value is null and you will be logged in instead. + - If **Confirm email** is enabled, the return value is the user and you won't be signed in automatically. + - If **Confirm email** is disabled, the return value is null and you will be signed in instead. - When the user confirms their email address, they are redirected to the [`SITE_URL`](https://supabase.com/docs/guides/auth/redirect-urls) by default. You can modify your `SITE_URL` or add additional redirect URLs in [your project](https://supabase.com/dashboard/project/_/auth/url-configuration). - To learn how to handle OTP links & OAuth refer to [initializing](/docs/reference/kotlin/initializing) - If signUpWith() is called for an existing confirmed user: @@ -3628,7 +3628,7 @@ functions: description: The JWT token. examples: - id: get-the-logged-in-user-with-the-current-existing-session - name: Get the logged in user with the current session + name: Get the signed-in user with the current session isSpotlight: true code: | ```kotlin @@ -3931,7 +3931,7 @@ functions: title: 'Send a password reset request' notes: | Sends a password reset request to the given email address. - - The password reset flow consist of 2 broad steps: (i) Allow the user to login via the password reset link; (ii) Update the user's password. + - The password reset flow consists of 2 broad steps: (i) Allow the user to sign in via the password reset link; (ii) Update the user's password. - The `resetPasswordForEmail()` only sends a password reset link to the user's email. To update the user's password, see [`updateUser()`](/docs/reference/kotlin/auth-updateuser). - The user gets redirected back to your app, assuming you setup [OTP handling](/docs/reference/kotlin/initializing) @@ -4197,7 +4197,7 @@ functions: val statusFlow = supabase.auth.mfa.statusFlow ``` - id: aal-enabled-for-current-session - name: Check whether the user is logged in using AAL2 + name: Check whether the user is signed in using AAL2 isSpotlight: true code: | ```kotlin diff --git a/apps/docs/spec/supabase_py_v2.yml b/apps/docs/spec/supabase_py_v2.yml index 5b77ff8d10e44..36e420ec03384 100644 --- a/apps/docs/spec/supabase_py_v2.yml +++ b/apps/docs/spec/supabase_py_v2.yml @@ -52,11 +52,11 @@ functions: - name: persist_session isOptional: true type: bool - description: Whether to persist a logged in session to storage. + description: Whether to persist a signed-in session to storage. - name: storage isOptional: true type: SyncSupportedStorage - description: A storage provider. Used to store the logged in session. + description: A storage provider. Used to store the signed-in session. - name: realtime isOptional: true type: string @@ -157,7 +157,7 @@ functions: The channel to use for sending messages. Only for phone signups. notes: | - - By default, the user needs to verify their email address before logging in. To turn this off, disable **Confirm email** in [your project](https://supabase.com/dashboard/project/_/auth/providers). + - By default, the user needs to verify their email address before signing in. To turn this off, disable **Confirm email** in [your project](https://supabase.com/dashboard/project/_/auth/providers). - **Confirm email** determines if users need to confirm their email address after signing up. - If **Confirm email** is enabled, a `user` is returned but `session` is null. - If **Confirm email** is disabled, both a `user` and a `session` are returned. @@ -165,7 +165,7 @@ functions: - If sign_up() is called for an existing confirmed user: - When both **Confirm email** and **Confirm phone** (even when phone provider is disabled) are enabled in [your project](/dashboard/project/_/auth/providers), an obfuscated/fake user object is returned. - When either **Confirm email** or **Confirm phone** (even when phone provider is disabled) is disabled, the error message, `User already registered` is returned. - - To fetch the currently logged-in user, refer to [`get_user()`](/docs/reference/python/auth-getuser). + - To fetch the currently signed-in user, refer to [`get_user()`](/docs/reference/python/auth-getuser). examples: - id: signup name: Sign up with an email and password @@ -457,7 +457,7 @@ functions: isOptional: true type: string notes: | - Log in an existing user with an email and password or phone and password. + Sign in an existing user with an email and password or phone and password. - Requires either an email and password or a phone number and password. examples: - id: sign-in-with-email-and-password @@ -1235,7 +1235,7 @@ functions: - The User model includes the following fields (since v2.28.0): `is_sso_user` (bool, defaults to `False`), `deleted_at` (optional string), and `banned_until` (optional string) in addition to the existing fields. examples: - id: get-the-logged-in-user-with-the-current-existing-session - name: Get the logged in user with the current existing session + name: Get the signed-in user with the current existing session isSpotlight: true code: | ``` @@ -1275,7 +1275,7 @@ functions: } ``` - id: get-the-logged-in-user-with-a-custom-access-token-jwt - name: Get the logged in user with a custom access token jwt + name: Get the signed-in user with a custom access token jwt isSpotlight: false code: | ``` @@ -1861,7 +1861,7 @@ functions: isOptional: false type: string notes: | - Log in an existing user by exchanging an Auth Code issued during the PKCE flow. + Sign in an existing user by exchanging an Auth Code issued during the PKCE flow. - Used when `flow_type` is set to `pkce` in client options. examples: @@ -3088,7 +3088,7 @@ functions: type: string description: Verification token received when the user completes the captcha on the site. notes: | - - The password reset flow consist of 2 broad steps: (i) Allow the user to login via the password reset link; (ii) Update the user's password. + - The password reset flow consists of 2 broad steps: (i) Allow the user to sign in via the password reset link; (ii) Update the user's password. - The `reset_password_for_email()` only sends a password reset link to the user's email. To update the user's password, see [`update_user()`](/docs/reference/python/auth-updateuser). - When the user clicks the reset link in the email they are redirected back to your application. @@ -7320,7 +7320,7 @@ functions: description: | The library accepts custom headers via the `headers` option. - Note: `supabase-py` automatically populates the `Authorization` header if there is a signed in user. + Note: `supabase-py` automatically populates the `Authorization` header if there is a signed-in user. isSpotlight: true code: | ```python diff --git a/apps/docs/spec/supabase_swift_v1.yml b/apps/docs/spec/supabase_swift_v1.yml index 6251a84fa52ef..e7c455a60ee55 100644 --- a/apps/docs/spec/supabase_swift_v1.yml +++ b/apps/docs/spec/supabase_swift_v1.yml @@ -81,7 +81,7 @@ functions: - id: sign-up title: 'signUp()' notes: | - - By default, the user needs to verify their email address before logging in. To turn this off, disable **Confirm email** in [your project](/dashboard/project/_/auth/providers). + - By default, the user needs to verify their email address before signing in. To turn this off, disable **Confirm email** in [your project](/dashboard/project/_/auth/providers). - **Confirm email** determines if users need to confirm their email address after signing up. - If **Confirm email** is enabled, a `user` is returned but `session` is null. - If **Confirm email** is disabled, both a `user` and a `session` are returned. @@ -89,7 +89,7 @@ functions: - If signUp() is called for an existing confirmed user: - If **Confirm email** is enabled in [your project](/dashboard/project/_/auth/providers), an obfuscated/fake user object is returned. - If **Confirm email** is disabled, the error message, `User already registered` is returned. - - To fetch the currently logged-in user, refer to [`getUser()`](/docs/reference/swift/get-user). + - To fetch the currently signed-in user, refer to [`getUser()`](/docs/reference/swift/get-user). examples: - id: sign-up name: Sign up @@ -165,7 +165,7 @@ functions: title: 'signInWithOTP()' notes: | - This method is used for passwordless sign-ins where a OTP is sent to the user's email or phone number. - - If the user doesn't exist, `signInWithOTP()` will signup the user instead. To restrict this behavior, you can set `shouldCreateUser` to `false`. + - If the user doesn't exist, `signInWithOTP()` will sign up the user instead. To restrict this behavior, you can set `shouldCreateUser` to `false`. - If you're using an email, you can configure whether you want the user to receive a magiclink or a OTP. - If you're using phone, you can configure whether you want the user to receive a OTP. - The magic link's destination URL is determined by the [`SITE_URL`](/docs/guides/auth/redirect-urls). @@ -327,14 +327,14 @@ functions: - Should be used only when you require the most current user data. For faster results, `session.user` is recommended. examples: - id: get-the-logged-in-user-with-the-current-existing-session - name: Get the logged in user with the current existing session + name: Get the signed-in user with the current existing session isSpotlight: true code: | ```swift let user = try await supabase.auth.user() ``` - id: get-the-logged-in-user-with-a-custom-access-token-jwt - name: Get the logged in user with a custom access token jwt + name: Get the signed-in user with a custom access token jwt isSpotlight: false code: | ```swift @@ -2731,7 +2731,7 @@ functions: - id: passing-custom-headers name: Passing custom headers description: | - You can pass custom headers to your function. Note: supabase-js automatically passes the `Authorization` header with the signed in user's JWT. + You can pass custom headers to your function. Note: supabase-swift automatically passes the `Authorization` header with the signed-in user's JWT. isSpotlight: true code: | ```swift diff --git a/apps/docs/spec/supabase_swift_v2.yml b/apps/docs/spec/supabase_swift_v2.yml index 132a3fd12b50b..71a1178071189 100644 --- a/apps/docs/spec/supabase_swift_v2.yml +++ b/apps/docs/spec/supabase_swift_v2.yml @@ -224,7 +224,7 @@ functions: - If signUp() is called for an existing confirmed user: - When both **Confirm email** and **Confirm phone** (even when phone provider is disabled) are enabled in [your project](/dashboard/project/_/auth/providers), an obfuscated/fake user object is returned. - When either **Confirm email** or **Confirm phone** (even when phone provider is disabled) is disabled, the error message, `User already registered` is returned. - - To fetch the currently logged-in user, refer to [`getUser()`](/docs/reference/swift/get-user). + - To fetch the currently signed-in user, refer to [`getUser()`](/docs/reference/swift/get-user). overwriteParams: - name: email isOptional: true @@ -335,7 +335,7 @@ functions: - Check the [User Sessions](/docs/guides/auth/sessions) docs for more information. - Use this to clean up any local storage your application has associated with the user. - `TOKEN_REFRESHED` - - Emitted each time a new access and refresh token are fetched for the signed in user. + - Emitted each time a new access and refresh token are fetched for the signed-in user. - It's best practice and highly recommended to extract the access token (JWT) and store it in memory for further use in your application. - Avoid frequent calls to `supabase.auth.session` for the same purpose. - There is a background process that keeps track of when the session should be refreshed so you will always receive valid tokens by listening to this event. @@ -4741,7 +4741,7 @@ functions: - id: passing-custom-headers name: Passing custom headers description: | - You can pass custom headers to your function. Note: supabase-js automatically passes the `Authorization` header with the signed in user's JWT. + You can pass custom headers to your function. Note: supabase-swift automatically passes the `Authorization` header with the signed-in user's JWT. isSpotlight: true code: | ```swift From 03227207430331869a4f7c25634e1e85aa25b6a7 Mon Sep 17 00:00:00 2001 From: Nik Richers Date: Thu, 3 Sep 2026 17:34:45 -0700 Subject: [PATCH 2/9] docs: add test-the-docs skill and pm-the-docs universe lookup (#49913) ## I have read the CONTRIBUTING.md file. YES ## What kind of change does this PR introduce? Docs authoring skills / contributor enablement. ## What is the current behavior? - The "Write the docs" bar asks for runnable examples, but skills stop at lint/build (`/review-the-docs`) and do not execute inline MDX snippets. - Cross-repo product grounding depends on a single-repo read; there is no skill guidance for `supabase/universe` when you have Supabase org access. ## What is the new behavior? - Adds `/test-the-docs` to run procedural snippets against a Docker-isolated local stack (`supabase start` in a temp project), with Verification table output. - Teaches `/pm-the-docs` cross-repo product lookup (`reference/universe-lookup.md`) with a capability gate: universe when you have Supabase org access (or a local clone), otherwise a first-class OSS public-search path. `ask-the-docs` stays docs-app only. - Updates the checklist mirror, CONTRIBUTING skills table, and light handoffs in `write-the-docs` / `review-the-docs`. ## Additional context Vault "Write the docs" checklist updated separately; Linear document needs a Claude-side delta sync after merge. ### Test plan - [ ] Symlinks: `.claude/skills` is a Git symlink to `../.agents/skills`; `.claude/skills/test-the-docs/SKILL.md` resolves - [ ] No hardcoded personal absolute paths under `.agents/skills/` - [ ] CONTRIBUTING lists skills including `/test-the-docs` - [ ] `/pm-the-docs` references `universe-lookup.md` capability gate; `/ask-the-docs` Related points there for product lookup - [ ] OSS path: no universe clone / submodule init when `gh api repos/supabase/universe` fails - [ ] Docker up: dry-run `/test-the-docs` against one MDX page with SQL/CLI (optional smoke) - [ ] Docker down: skill documents graceful `deferred` (not silent skip) ## Summary by CodeRabbit - **New Features** - Added documentation guidance for testing runnable examples in an isolated local environment. - Added cross-repository product lookup guidance, including capability checks and source tracking. - Added verification report templates with standardized results and environment details. - **Documentation** - Expanded authoring, review, self-review, and contribution guidance. - Improved safety instructions for local snippet testing, including credential protection and cleanup. - Updated repository layout, tooling, links, and workflow references for documentation skills. --------- Co-authored-by: Nik Richers --- .agents/skills/ask-the-docs/SKILL.md | 5 +- .agents/skills/pm-the-docs/SKILL.md | 30 ++- .../pm-the-docs/reference/universe-lookup.md | 96 +++++++++ .../reference/write-the-docs-checklist.md | 63 +++--- .agents/skills/review-the-docs/SKILL.md | 5 +- .agents/skills/test-the-docs/SKILL.md | 96 +++++++++ .../test-the-docs/reference/sandbox-setup.md | 83 ++++++++ .../reference/snippet-classes.md | 28 +++ .../reference/verification-report.md | 38 ++++ .../skills/test-the-docs/sandbox/.empty/.keep | 1 + .../skills/test-the-docs/sandbox/.gitignore | 2 + .../skills/test-the-docs/sandbox/Dockerfile | 34 ++++ .../skills/test-the-docs/sandbox/compose.yaml | 81 ++++++++ .agents/skills/test-the-docs/sandbox/run.sh | 189 ++++++++++++++++++ .agents/skills/write-the-docs/SKILL.md | 7 +- apps/docs/CONTRIBUTING.md | 5 +- 16 files changed, 720 insertions(+), 43 deletions(-) create mode 100644 .agents/skills/pm-the-docs/reference/universe-lookup.md create mode 100644 .agents/skills/test-the-docs/SKILL.md create mode 100644 .agents/skills/test-the-docs/reference/sandbox-setup.md create mode 100644 .agents/skills/test-the-docs/reference/snippet-classes.md create mode 100644 .agents/skills/test-the-docs/reference/verification-report.md create mode 100644 .agents/skills/test-the-docs/sandbox/.empty/.keep create mode 100644 .agents/skills/test-the-docs/sandbox/.gitignore create mode 100644 .agents/skills/test-the-docs/sandbox/Dockerfile create mode 100644 .agents/skills/test-the-docs/sandbox/compose.yaml create mode 100755 .agents/skills/test-the-docs/sandbox/run.sh diff --git a/.agents/skills/ask-the-docs/SKILL.md b/.agents/skills/ask-the-docs/SKILL.md index f7ed9c49fa4b1..3f87e86fefca9 100644 --- a/.agents/skills/ask-the-docs/SKILL.md +++ b/.agents/skills/ask-the-docs/SKILL.md @@ -125,7 +125,10 @@ write it down. - [`pm-the-docs`](../pm-the-docs/SKILL.md) — audience, stage, and cross-cutting scope calls (Frame stage of the "Write the docs" checklist, - mirrored in `pm-the-docs`'s reference file). + mirrored in `pm-the-docs`'s reference file). Cross-repo **product** lookup + (universe) lives there, not in this skill. +- [`test-the-docs`](../test-the-docs/SKILL.md) — execute docs snippets against a + Docker-isolated local stack; verification report. - [`work-linear-issue`](https://github.com/supabase/docs-agent-skills/blob/main/.claude/skills/work-linear-issue/SKILL.md) — implementing assigned DOCS-\* tickets. - [`review-the-docs`](../review-the-docs/SKILL.md) — reviewing open docs diff --git a/.agents/skills/pm-the-docs/SKILL.md b/.agents/skills/pm-the-docs/SKILL.md index 3d3d2a4867b20..d17a30cab7093 100644 --- a/.agents/skills/pm-the-docs/SKILL.md +++ b/.agents/skills/pm-the-docs/SKILL.md @@ -3,10 +3,12 @@ name: pm-the-docs description: >- Docs-PM decision support for the "Write the docs" authoring process — makes audience, stage, and cross-cutting scope calls during the Frame - and Shape stages, and helps decide when a docs question needs to - self-serve vs. escalate to a docs PM. Use when framing a new docs page - or launch, deciding what product stage or audience a feature targets, - or judging whether a docs question needs PM sign-off. + and Shape stages (including cross-repo product lookup via universe when + accessible, else the public OSS path), and helps decide when a docs + question needs to self-serve vs. escalate to a docs PM. Use when framing + a new docs page or launch, deciding what product stage or audience a + feature targets, judging whether a docs question needs PM sign-off, or + confirming which product repos a launch spans. --- # PM the docs @@ -17,17 +19,26 @@ Backs the Frame and Shape stages of the "Write the docs" checklist (mirrored in - Starting a new docs page or launch and need to state the product stage, audience, and "why" before drafting (Frame). - Deciding content type, IA placement, or prerequisites for a page (Shape). +- Judging whether a launch spans multiple product repos (CLI, Auth, migrations, platform, …) — see [reference/universe-lookup.md](reference/universe-lookup.md). - Unsure whether a docs question is self-serve or needs a docs PM's sign-off. -**Not for** drafting content itself (see [`write-the-docs`](../write-the-docs/SKILL.md)), restructuring existing pages (see [`edit-the-docs`](../edit-the-docs/SKILL.md)), or docs-app architecture/IA placement mechanics (see [`ask-the-docs`](../ask-the-docs/SKILL.md)). +**Not for** drafting content itself (see [`write-the-docs`](../write-the-docs/SKILL.md)), restructuring existing pages (see [`edit-the-docs`](../edit-the-docs/SKILL.md)), running snippets (see [`test-the-docs`](../test-the-docs/SKILL.md)), or docs-app architecture/IA placement mechanics (see [`ask-the-docs`](../ask-the-docs/SKILL.md)). + +## Reference files + +| File | What's inside | +| ------------------------------------------------------------------------------ | -------------------------------------------------------------------------- | +| [reference/write-the-docs-checklist.md](reference/write-the-docs-checklist.md) | Six-stage authoring checklist mirror | +| [reference/universe-lookup.md](reference/universe-lookup.md) | Cross-repo product lookup: capability gate, universe accelerator, OSS path | ## Answering a scope/stage/audience question 1. Read the relevant stage in [reference/write-the-docs-checklist.md](reference/write-the-docs-checklist.md) — its checkboxes state exactly what needs deciding. 2. Read whatever context exists for the feature: the linked issue/project, the PRD, the shipped code or PR. When code and PRD disagree, the code wins for behavior claims. -3. Answer the checklist's questions directly: product stage, audience and job-to-be-done, the one-line "why," content type, IA placement, prerequisites. -4. Distinguish **confirmed fact** (stated in the ticket/PRD/code) from **inference** (your best read) — flag inference explicitly rather than presenting it as settled. -5. If a decision is genuinely open at the org level (not a docs authoring call), say so and name who should decide instead of inventing an answer to look complete. +3. When scope may span services (CLI, Auth, migrations, Dashboard, platform, …), follow [reference/universe-lookup.md](reference/universe-lookup.md) **capability gate** before settling Frame/Shape; use universe only if accessible, otherwise the OSS path. Record which repos you searched. +4. Answer the checklist's questions directly: product stage, audience and job-to-be-done, the one-line "why," content type, IA placement, prerequisites. +5. Distinguish **confirmed fact** (stated in the ticket/PRD/code) from **inference** (your best read) — flag inference explicitly rather than presenting it as settled. +6. If a decision is genuinely open at the org level (not a docs authoring call), say so and name who should decide instead of inventing an answer to look complete. ## Self-serve vs. escalate @@ -37,7 +48,8 @@ Escalate to your docs team's PM when scope or stage is unclear, you need a revie ## Related skills -- [`ask-the-docs`](../ask-the-docs/SKILL.md) — IA placement and docs-app architecture (Shape stage) +- [`ask-the-docs`](../ask-the-docs/SKILL.md) — IA placement and docs-app architecture (Shape stage). Cross-repo **product** lookup lives here in `universe-lookup.md`, not in `ask-the-docs`. - [`write-the-docs`](../write-the-docs/SKILL.md) — drafting once Frame/Shape are settled +- [`test-the-docs`](../test-the-docs/SKILL.md) — run snippets against a Docker-isolated local stack; verification report - [`edit-the-docs`](../edit-the-docs/SKILL.md) — restructure and improve existing pages - [`review-the-docs`](../review-the-docs/SKILL.md) — self-review and PR review stages diff --git a/.agents/skills/pm-the-docs/reference/universe-lookup.md b/.agents/skills/pm-the-docs/reference/universe-lookup.md new file mode 100644 index 0000000000000..0ee205b50eb07 --- /dev/null +++ b/.agents/skills/pm-the-docs/reference/universe-lookup.md @@ -0,0 +1,96 @@ +# Cross-repo product lookup + +Cross-repo product search for Frame/Shape when a feature may span services. Use during `/pm-the-docs`, not `/ask-the-docs` (`ask-the-docs` stays on `apps/docs` architecture). + +**Cross-repo confirmation is required for everyone.** [`supabase/universe`](https://github.com/supabase/universe) is an optional accelerator when you have Supabase org access to that private meta-repo (and ideally a local clone). Contributors without that access use the OSS path below — that is a successful outcome, not a failure. + +## Capability gate + +Run this gate before any universe clone or submodule command. + +```mermaid +flowchart TD + start[Cross-repo grounding needed] + clone{"Local universe root exists?"} + ghApi{"gh api repos/supabase/universe succeeds?"} + useUniverse[Use universe clone + rg in repos/] + ossPath[OSS path: public gh search + linked product repos] + start --> clone + clone -->|yes| useUniverse + clone -->|no| ghApi + ghApi -->|yes Supabase org access| useUniverse + ghApi -->|no 404/403| ossPath +``` + +### 1. Local clone? + +Resolve the universe root in order (do not hardcode machine-specific absolute paths in committed files): + +1. `$SUPABASE_UNIVERSE_ROOT` (if set) +2. `$HOME/GitHub/supabase/universe` + +```bash +UNIVERSE_ROOT="${SUPABASE_UNIVERSE_ROOT:-$HOME/GitHub/supabase/universe}" +[[ -d "$UNIVERSE_ROOT/.git" || -f "$UNIVERSE_ROOT/.git" ]] && echo "local universe ok" +``` + +If that checkout exists → **accelerator path** (skip the `gh api` probe). + +### 2. Else probe org access (read-only, no clone) + +```bash +gh api repos/supabase/universe -q .full_name +``` + +| Result | Next step | +| ------ | --------- | +| Success (`supabase/universe`) | Accelerator path: you **may** clone with `--recurse-submodules` (or ask the user to), then search | +| 404, 403, or other failure | **OSS path only** — do **not** run `git clone` or `git submodule update` against universe | + +## OSS path (always valid) + +When the gate says universe is unavailable: + +- Search public code: `gh search code --owner supabase ''` (plus other public owners named in the ticket) +- Read any product repo already checked out or linked from Linear / the PR +- Prefer `supabase/supabase` in-tree sources when that is enough +- In the Frame/Shape summary, record `universe: unavailable (OSS)` and list the public sources used + +Never treat missing universe access as a blocker or an incomplete Frame/Shape. + +## Accelerator: universe (when accessible) + +Prefer an existing local clone. Only init or update submodules after the gate succeeds: + +```bash +cd "$UNIVERSE_ROOT" +git submodule update --init --recursive +``` + +Private submodules (`platform`, `branching`) may need a PAT. If those fail, note the gap and continue with public submodules plus the OSS search path. + +### Where to look + +Start from the universe README "Finding your way around" table, then `rg` inside the relevant submodule: + +| Looking for… | Start in | +| ------------ | -------- | +| Schema, extensions, RLS | `repos/postgres/`, `repos/postgrest/`, `repos/pg-toolbelt/` | +| Auth flows | `repos/auth/`, `auth-js` under `repos/supabase-js/` | +| Realtime / Storage / Edge Functions | `repos/realtime/`, `repos/storage/`, `repos/edge-runtime/` | +| Dashboard / Studio | `repos/supabase/apps/studio` | +| Management API / hosted infra | `repos/platform/` (private) | +| CLI, local dev, `config.toml` | `repos/cli/` | +| Docs & self-hosting Compose | `repos/supabase/` (`apps/docs`, `docker/`) | + +When scope is unknown, search initialized `repos/**` with a tight pattern rather than reading entire trees. + +## How to use in Frame / Shape + +1. Name the product surfaces the launch might touch (CLI, Auth, migrations, Dashboard, …). +2. Run the **capability gate**. +3. Resolve surfaces to repos (universe submodules **or** public search / linked checkouts). +4. Confirm with a short search whether behavior lives in one repo or several. +5. Record in the Frame/Shape summary: gate result (`universe: available` or `universe: unavailable (OSS)`), repos consulted, cross-cutting vs single-repo, and any gaps. + +Always distinguish confirmed fact from inference. diff --git a/.agents/skills/pm-the-docs/reference/write-the-docs-checklist.md b/.agents/skills/pm-the-docs/reference/write-the-docs-checklist.md index 5bffc867c62be..afe39dc5a9dfd 100644 --- a/.agents/skills/pm-the-docs/reference/write-the-docs-checklist.md +++ b/.agents/skills/pm-the-docs/reference/write-the-docs-checklist.md @@ -1,61 +1,71 @@ # Write the docs -> Mirrors Supabase's proposed "Write the docs" process as of 2026-08-10. Process specifics may still evolve. - A practical six-stage checklist and quality standard for planning, drafting, and reviewing product documentation. +**P** = Product +**E** = Engineering +**Docs** = Docs team + +## Authoring + +Six short stages. Keep it lightweight; the point is to make good docs the default, not to add ceremony. + +_Self-serve first ([agent skills](../../../../apps/docs/CONTRIBUTING.md#ai-agent-skills-for-docs-authoring)), ask your docs team's PM as needed._ + ## What good looks like - The **why** is explicit: a reader learns what problem this solves and when to reach for it, not only the steps. -- The **content type is deliberate** and consistent within the page. +- The content **type is deliberate** and consistent within the page. - **Audience and prerequisites** are stated up front. -- At least one **example is runnable and has been run** (commands, code, expected result). -- **Correct stage** is stated; limitations are named honestly. +- **Examples are runnable and have been tested** (commands, code, expected result) — verify with `/test-the-docs` against a Docker-isolated local stack, not production. +- **Correct stage** like GA is stated; limitations are named honestly. - The page **lives in the right place** in the IA and links to and from related pages. -- Terminology and formatting match existing docs (defer to the style guide once one lands). +- Terminology and formatting match existing docs (and style guide once it lands). -## 1. Frame +### 1. Frame -_Skills:_ `ask-the-docs` to see how the surface works today; `pm-the-docs` for audience, stage, and cross-cutting scope calls. +_Skills:_ `/ask-the-docs` for how the docs surface works today; `/pm-the-docs` for audience, stage, and cross-cutting scope (cross-repo span via universe when accessible — see [universe-lookup.md](universe-lookup.md)). - [ ] P: State the product stage (private/public alpha, beta, GA) - [ ] P: Name the audience and the job they are trying to do - [ ] P: Write one line on _why_ the feature exists (the problem it solves), not only what it does -## 2. Shape +### 2. Shape -_Skill:_ `ask-the-docs` for IA placement, architecture, and where content lives. +_Skill:_ `/ask-the-docs` for IA placement, architecture, and where content lives. - [ ] P: Pick the content type(s): tutorial (learning), how-to (a task), reference (lookup), explanation (the why). Do not mix types on one page (refer to [Diátaxis](https://diataxis.fr/)) - [ ] P: Decide where the page lives in the existing IA and what links in and out (avoid orphan pages) - [ ] P: List prerequisites and assumed knowledge up front -## 3. Draft +### 3. Draft -_Skill:_ `write-the-docs` to draft net-new content grounded in Linear and the code. +_Skill:_ `/write-the-docs` to draft net-new content grounded in Linear and the code (`/pm-the-docs` → universe when accessible, else public search / named product repos). - [ ] P: Lead with the why and the outcome, then the how/what (product story first) -- [ ] P: Include at least one runnable, copy-pasteable example that you have actually run +- [ ] P: Include at least one runnable, copy-pasteable example that you have actually run (or will run in Self-review via `/test-the-docs`) +- [ ] P/E: Cross-repo behavior confirmed via universe when accessible, else public `gh search` / named product repos when the feature is not confined to `supabase/supabase` (lookup via `/pm-the-docs`, not `/ask-the-docs`) - [ ] E: Contribute technical depth and verify accuracy (APIs, limits, edge cases) - [ ] P: Call out the current stage inline and any known limitations -When the work is improving an existing page (restructure, reorder, connective text, brevity) rather than authoring net-new content, use `edit-the-docs` instead of `write-the-docs`. +When the work is improving an existing page (restructure, reorder, connective text, brevity) rather than authoring net-new content, use `/edit-the-docs` instead of `/write-the-docs`. -## 4. Self-review against the bar +### 4. Self-review against the bar -_Skill:_ `review-the-docs` — [Local self-review](../../review-the-docs/SKILL.md#local-self-review-no-open-pr) on your own branch before opening the PR. +_Skills:_ `/review-the-docs` for [local self-review](../../review-the-docs/SKILL.md#local-self-review-no-open-pr) before opening the PR; `/test-the-docs` to run snippets and produce a verification report. - [ ] P/E: Check the draft against "What good looks like" above before opening the PR -- [ ] P/E: Follow authoring-experience standards and tooling when available +- [ ] P/E: `/test-the-docs` run; verification report ready for the PR body +- [ ] P/E: Follow Authoring Experience standards and tooling when available -## 5. PR review +### 5. PR review -_Skill:_ `review-the-docs` to triage, classify, verify the build, and report. +_Skill:_ `/review-the-docs` to triage, classify, verify the build, and report. - [ ] P/E: Open the PR and request review per the rules of engagement - [ ] Docs: Review against the published bar -## 6. Keep it honest +### 6. Keep it honest - [ ] P: Keep the product launch checklist's "start on day 1" docs gate honest through ship (update as stage or behavior changes) @@ -63,17 +73,12 @@ _Skill:_ `review-the-docs` to triage, classify, verify the build, and report. **Self-serve when:** the checklist above is clear, standards exist, and you know the product stage and audience. -**Ask when:** scope or stage is unclear, you need a review path, the bar is ambiguous, or the launch docs touch cross-cutting surfaces (quickstarts, API keys, tutorials, onboarding, platform concepts). +**Ask when:** scope or stage is unclear, you need a review path, the bar is ambiguous, or the launch docs touch cross-cutting surfaces (quick starts, API keys, tutorials, onboarding, platform concepts). -**What to expect:** the docs PM is the point of contact for questions and review against the bar. +**What to expect:** the docs PM is the point of contact for questions, skills enablement, and review against the bar. **Where to ping:** your team's PR-review channel and current docs PM — check your contributor guide for who that is today. -## Reference - -Role prefixes: +## Resources -- **P** = Product. The product lead / area PM who writes the docs. -- **E** = Engineering. Contributes technical depth and verifies accuracy. -- **P/E** = Product and Engineering together. -- **Docs** = Docs team, the reviewer. +Skills for this checklist: [AI agent skills for docs authoring](../../../../apps/docs/CONTRIBUTING.md#ai-agent-skills-for-docs-authoring) (`/pm-the-docs`, `/ask-the-docs`, `/write-the-docs`, `/edit-the-docs`, `/test-the-docs`, `/review-the-docs`). diff --git a/.agents/skills/review-the-docs/SKILL.md b/.agents/skills/review-the-docs/SKILL.md index 2b42ac33c50ce..0316e3fc613f2 100644 --- a/.agents/skills/review-the-docs/SKILL.md +++ b/.agents/skills/review-the-docs/SKILL.md @@ -69,7 +69,8 @@ pnpm build:reference-markdown # when reference pipeline changed ``` 4. Spot-check frontmatter, internal links, and nav wiring for content changes. -5. Write a short **self-review note** (blockers vs nits) suitable to paste into the future PR body under a "Self-review" heading. +5. **Offer runnable verification** — for content/tutorial PRs with new or changed procedural fenced blocks, ask whether to run [`test-the-docs`](../test-the-docs/SKILL.md). Prerequisites are class-specific (Docker Compose stack profile for DB/API; examples profile for `example-app`). If accepted, include the verification report; if declined or a required prerequisite for that class is missing, record credible `deferred` reasons for those artifacts only. Do not reimplement sandbox execution here. +6. Write a short **self-review note** (blockers vs nits) suitable to paste into the future PR body under a "Self-review" heading. Then open the PR and continue with open-PR review if a second pass is needed. @@ -216,6 +217,7 @@ Checklist: - [ ] `$CodeSample` paths match existing example directories - [ ] Admonitions, tabs, and partial includes render sensibly in PR preview - [ ] No accidental whitespace-only or empty sections where components were removed +- [ ] Offered [`test-the-docs`](../test-the-docs/SKILL.md) for new/changed procedural snippets; verification report present or credible `deferred` reasons recorded Compare PR preview URL (from Vercel/deployment comment) against production for visual regressions when layout components are involved. @@ -239,6 +241,7 @@ Checklist: - [ ] MDX steps match example code after `pnpm codegen:examples` (if `$CodeSample` used) - [ ] Env var names and Supabase client setup match current `@supabase/ssr` patterns - [ ] Example pins catalog versions — no `"latest"` for in-repo packages +- [ ] Offered [`test-the-docs`](../test-the-docs/SKILL.md) for procedural tutorial steps (or `deferred` with reason) - [ ] **Platform E2E** (when auth involved): SQL migration applied, auth flow walked, profiles verified — see `work-linear-issue` Phase 3 --- diff --git a/.agents/skills/test-the-docs/SKILL.md b/.agents/skills/test-the-docs/SKILL.md new file mode 100644 index 0000000000000..1261958ff9576 --- /dev/null +++ b/.agents/skills/test-the-docs/SKILL.md @@ -0,0 +1,96 @@ +--- +name: test-the-docs +description: >- + Execute runnable docs snippets and examples inside a disposable Docker Compose + sandbox (runner container + local Supabase stack via `supabase start`). Use + after Draft or during Self-review when asked to test the docs, fact-check + CLI/SQL/code samples, or produce a verification report for a docs PR. + Complements review-the-docs lint/build checks; does not replace them. +--- + +# Test the docs + +Runs procedural docs content **inside disposable containers**, not on the host shell and not against production. Produces a verification report for the PR body / self-review note. + +For lint, markdown rebuilds, example-app triage, and PR review, use [`review-the-docs`](../review-the-docs/SKILL.md). For Frame/Shape and cross-repo product lookup, use [`pm-the-docs`](../pm-the-docs/SKILL.md). + +## When to invoke + +- After Draft, before or during Self-review (checklist Stage 4). +- Standalone: "test the docs", "fact-check these snippets", "run the examples". +- Content or tutorial PRs that add or change procedural fenced blocks. + +**Not for:** generated reference pages, docs-app architecture questions, or hosted/production projects. + +## Core rules + +1. **Never run against production.** Local stack or temp dir only. +2. **Never run MDX fences on the host shell.** Use the Compose sandbox — see [reference/sandbox-setup.md](reference/sandbox-setup.md) and [`sandbox/run.sh`](sandbox/run.sh). +3. **Proportional:** Tier A (one end-to-end path) is required; Tier B spot-checks new/changed procedural blocks, not every fence on every page. +4. **Product bugs** found while testing get linked or filed separately; fix docs only when the docs are wrong. + +## Phases + +### 1. Scope + +From explicit MDX paths, or: + +```bash +git diff --name-only master...HEAD -- 'apps/docs/content/**' +``` + +Skip generated reference output under `features/docs/generated/`. + +### 2. Extract + +List runnable artifacts from changed MDX: + +- Fenced blocks: `bash`, `sh`, `sql`, `javascript`, `typescript`, `tsx`, `jsx` +- `$CodeSample` paths → treat as `example-app` (build under `examples/`) +- Skip: `mermaid`, incomplete illustrative fragments, partial-only includes + +### 3. Classify + +Assign each artifact a class per [reference/snippet-classes.md](reference/snippet-classes.md): + +| Class | Action | +| --------------------- | ---------------------------------------------- | +| `runnable-local` | Run in temp stack / temp dir | +| `runnable-with-setup` | Run after documented setup (migrations, seed) | +| `example-app` | `npm install && npm run build` in `examples/…` | +| `illustrative-only` | No run required | +| `deferred` | Record reason; do not silently skip | + +### 4. Sandbox setup + +Follow [reference/sandbox-setup.md](reference/sandbox-setup.md) and drive lifecycle with [`sandbox/run.sh`](sandbox/run.sh): + +1. Refuse if the **host** is running as root. +2. Require `docker` + `docker info` + `docker compose` on the host for any in-container run. +3. Gate profiles **per artifact class**: + - `runnable-local` / `runnable-with-setup` that need DB/API: `./sandbox/run.sh up-stack` (DinD + runner → `supabase init` / `supabase start` in `/work`). + - CLI-only blocks with no DB: still use a runner profile so fences stay off-host; skip `supabase start` when unused. + - `example-app`: `TTD_EXAMPLE_DIR=/examples/ ./sandbox/run.sh up-examples` (Node in runner; **no** DinD). Do **not** defer solely because the host lacks a global Supabase CLI. +4. Always `./sandbox/run.sh down` when finished (cleanup trap on the host session). +5. Capture connection **URLs only** inside the runner; never paste credential fields into notes or logs. + +If a **required** prerequisite for that artifact is unavailable, mark that artifact `deferred` with the specific reason — never silent skip, and do not defer unrelated classes. + +### 5. Execute + +- **Tier A:** one copy-pasteable end-to-end path from the page. +- **Tier B:** each new/changed block classified `runnable-*` **or** `example-app` (build and record the result). +- Run every fence via `./sandbox/run.sh exec` or `exec-timeout` (never a bare host shell). +- Bound every artifact: default **60s** for shell / SQL / JS / TypeScript / `tsx` / `jsx`; allow longer for `example-app` install/build (e.g. **5m**). On timeout, kill the process **group** inside the runner, then record `fail` or `deferred` with reason. +- `curl` / `wget` only to filtered stack URLs (or page-documented local endpoints). `npm` / `npx` / `node` only for mounted `example-app` builds. +- Capture exit code, stdout/stderr (redact secrets), and observed vs expected behavior. + +### 6. Report + +Write a verification report per [reference/verification-report.md](reference/verification-report.md) for the PR body / self-review note. + +## Related skills + +- [`write-the-docs`](../write-the-docs/SKILL.md) — Draft; hands off here before PR +- [`review-the-docs`](../review-the-docs/SKILL.md) — lint/build/classify; consumes verification report +- [`pm-the-docs`](../pm-the-docs/SKILL.md) — Frame/Shape; universe for cross-repo product lookup diff --git a/.agents/skills/test-the-docs/reference/sandbox-setup.md b/.agents/skills/test-the-docs/reference/sandbox-setup.md new file mode 100644 index 0000000000000..647d9840076c2 --- /dev/null +++ b/.agents/skills/test-the-docs/reference/sandbox-setup.md @@ -0,0 +1,83 @@ +# Sandbox setup + +Containerized local execution for `/test-the-docs`. The **host** only starts Docker Compose and tears it down. Every MDX fence (shell, SQL, JS/TS, example-app builds) runs **inside** the disposable `runner` container — never as a host shell. + +Assets live in [`../sandbox/`](../sandbox/): `compose.yaml`, `Dockerfile`, `run.sh`. + +## Threat model and guardrails + +| Layer | What it does | +| ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Host | `docker compose` lifecycle only (`run.sh up-*` / `down`). No fence execution. | +| Runner container | Executes fences as non-root `runner` (uid 1001). No `$HOME` mount. Work dir is `/work`; optional read-only `/examples`. | +| DinD (`stack` profile) | Privileged `docker:dind` runs an isolated Docker daemon. `supabase start` creates stack containers **inside DinD**. The runner shares DinD’s network namespace (`network_mode: service:dind`) so `127.0.0.1` healthchecks and client URLs work. Residual risk: privileged DinD; mitigate with ephemeral project names and `run.sh down`. | +| Examples profile | No DinD and no docker.sock — Node-only builds. | + +This skill is for docs authors and reviewers verifying intended content. It is not unattended CI over arbitrary hostile input. + +Guardrails: + +- **Fences in-container only.** Never run MDX fences on the host shell. Use `./sandbox/run.sh exec` or `exec-timeout`. +- **Local stack only.** Reject snippets that target hosted or production Supabase projects. +- **No secrets in notes.** Never paste `PUBLISHABLE_KEY`, `SECRET_KEY`, `JWT_SECRET`, `ANON_KEY`, `SERVICE_ROLE_KEY`, `S3_PROTOCOL_ACCESS_KEY_ID`, `S3_PROTOCOL_ACCESS_KEY_SECRET`, or other keys into the verification report, PR body, or chat logs. Capture **URLs only** from `supabase status -o env`. +- **`curl` / `wget`.** Only to URLs from the filtered status capture (`API_URL`, `DB_URL`, `DATABASE_URL`), or to local endpoints the page under test documents. Mark other targets `deferred`. +- **`npm` / `npx` / `node`.** Only for `example-app` artifacts. Mount the app read-only at `/examples`, copy into `/work/example`, then `npm install && npm run build` (or the page’s documented build). Arbitrary `node -e`, remote `npx`, or Node from unrelated bash fences → `deferred`. +- **Prefer page commands.** Run documented steps from the MDX under test. +- **Fail closed** when Docker/Compose prerequisites for that artifact class are missing (see skill Phase 4). + +## Host prerequisites (fail closed) + +```bash +if [[ "$(id -u)" = "0" ]]; then + echo "error: refuse to run as root" >&2 + exit 1 +fi +command -v docker >/dev/null || { echo "error: docker not found" >&2; exit 1; } +docker info >/dev/null 2>&1 || { echo "error: Docker is not running" >&2; exit 1; } +docker compose version >/dev/null || { echo "error: docker compose not available" >&2; exit 1; } +``` + +The host does **not** need a global `supabase` CLI or Node for stack/example runs; those tools live in the runner image. If Docker/Compose is unavailable, mark artifacts that need the runner `deferred`. + +`run.sh` creates temp work/output dirs world-writable (`chmod 0777`) so the non-root runner (`uid 1001`) can write into the host bind mounts. + +## Lifecycle (`run.sh`) + +From `.agents/skills/test-the-docs/sandbox/`: + +```bash +# Optional: pin dirs / project name for the session +eval "$(./run.sh env)" + +# Stack profile: DinD + runner → supabase init/start inside /work +./run.sh up-stack + +# Capture URLs only inside the runner (never log credential fields) +./run.sh exec -- bash -lc ' + eval "$(supabase status -o env | grep -E "^(API_URL|DB_URL|DATABASE_URL)=")" + echo "API_URL is set (value omitted from logs)" +' + +# Run a fence with a deadline (process group killed on timeout) +./run.sh exec-timeout 60 -- bash -lc 'eval "$(supabase status -o env | grep -E "^(API_URL|DB_URL|DATABASE_URL)=")"; psql "$DB_URL" -c "select 1"' + +# Examples profile (no DinD): mount the app, then build +TTD_EXAMPLE_DIR=/path/to/repo/examples/auth/hono ./run.sh up-examples +./run.sh exec-timeout 300 -- bash -lc 'cd /work/example && npm install && npm run build' + +# Always tear down +./run.sh down +``` + +## Profiles + +| Profile | Services | Isolation | Use when | +| ---------- | ----------------------- | -------------------------------- | --------------------------------------------- | +| `stack` | `dind` + `runner-stack` | Privileged DinD; fences off-host | SQL, CLI, client calls against local Supabase | +| `examples` | `runner` | No Docker daemon in-sandbox | `example-app` install/build only | + +Do not start the stack unless the artifact needs it. + +## Teardown + +Always `./run.sh down` (stops `supabase` project containers when possible, `compose down -v`, removes temp work/output dirs). Leave Docker Desktop running for the next session. diff --git a/.agents/skills/test-the-docs/reference/snippet-classes.md b/.agents/skills/test-the-docs/reference/snippet-classes.md new file mode 100644 index 0000000000000..5823c9e9988ad --- /dev/null +++ b/.agents/skills/test-the-docs/reference/snippet-classes.md @@ -0,0 +1,28 @@ +# Snippet classes + +Classify each extracted artifact before running it. + +| Class | Meaning | Run? | +| --------------------- | -------------------------------------------------------------------------------- | -------------------------------------- | +| `runnable-local` | Complete CLI, SQL, or script that works against a local stack or temp dir | Yes | +| `runnable-with-setup` | Needs migrations, seed data, `.env`, or prior steps from the same page | Yes, after setup | +| `example-app` | `$CodeSample` or path under `examples/` | Build (`npm install && npm run build`) | +| `illustrative-only` | Incomplete on purpose, omits required context, or is conceptual | No | +| `deferred` | Needs production, paid feature, destructive op, or missing required prerequisite | No — record reason | + +## Safety + +- Prefer read-only SQL and non-destructive CLI flags. +- Never target a linked hosted/production project from this skill. +- Do not print secrets (service role keys, PATs) into Verification notes or logs. +- Mark incomplete copy-paste blocks `illustrative-only` rather than forcing a run that cannot succeed. +- Execute fences only inside the Compose runner per [sandbox-setup.md](sandbox-setup.md). Restrict `curl`/`wget` to filtered stack URLs; restrict `npm`/`npx`/`node` to `example-app` mounts. Mark out-of-policy fences `deferred`. + +## Language heuristics + +| Fence | Typical class | +| ------------------------------------------- | --------------------------------------------------------------------------- | +| `sql` | `runnable-local` or `runnable-with-setup` if ordered migrations | +| `bash` / `sh` | `runnable-local` if self-contained; else `deferred` / `illustrative-only` | +| `javascript` / `typescript` / `tsx` / `jsx` | Often `illustrative-only` unless a full runnable script or example-app path | +| `mermaid` | Skip (not executable) | diff --git a/.agents/skills/test-the-docs/reference/verification-report.md b/.agents/skills/test-the-docs/reference/verification-report.md new file mode 100644 index 0000000000000..0d19fd3209309 --- /dev/null +++ b/.agents/skills/test-the-docs/reference/verification-report.md @@ -0,0 +1,38 @@ +# Verification report + +Paste into the PR body or self-review note under a **Verification** heading. + +## Template + +```markdown +## Verification (`/test-the-docs`) + +| Snippet / step | Class | Sandbox | Result | Notes | +| ----------------------------- | -------------- | --------------------------------- | -------- | ------------------------ | +| e.g. `create type …` SQL | runnable-local | Compose runner + `supabase start` | pass | | +| e.g. `supabase db diff` | runnable-local | Compose runner + local stack | fail | product bug → link issue | +| e.g. paid Dashboard-only step | deferred | — | deferred | needs hosted project | + +**Tier A path:** + +**Environment:** Docker Desktop ; compose sandbox (`sandbox/run.sh`); fences in-container only +``` + +Do **not** put secrets (`JWT_SECRET`, `ANON_KEY`, `SERVICE_ROLE_KEY`, access tokens) in Notes or Environment. + +## Results + +| Result | Meaning | +| ---------- | -------------------------------------------------------------------- | +| `pass` | Command exited 0 and matched expected behavior | +| `fail` | Ran but wrong output / non-zero exit — docs wrong **or** product bug | +| `deferred` | Not run; reason required in Notes | +| `skipped` | Out of scope (`illustrative-only`) | + +## Product bugs + +If the snippet matches the code and still fails: + +1. Prefer linking an existing issue in the owning repo. +2. Otherwise note the repro in the PR and file/follow up with the product owner. +3. Do not "fix" the docs to hide a real platform bug without calling it out. diff --git a/.agents/skills/test-the-docs/sandbox/.empty/.keep b/.agents/skills/test-the-docs/sandbox/.empty/.keep new file mode 100644 index 0000000000000..9c664e38e3760 --- /dev/null +++ b/.agents/skills/test-the-docs/sandbox/.empty/.keep @@ -0,0 +1 @@ +# Keep empty bind-mount target for compose when no example is mounted. diff --git a/.agents/skills/test-the-docs/sandbox/.gitignore b/.agents/skills/test-the-docs/sandbox/.gitignore new file mode 100644 index 0000000000000..6d9a510bfea4d --- /dev/null +++ b/.agents/skills/test-the-docs/sandbox/.gitignore @@ -0,0 +1,2 @@ +.state/ +!.empty/.keep diff --git a/.agents/skills/test-the-docs/sandbox/Dockerfile b/.agents/skills/test-the-docs/sandbox/Dockerfile new file mode 100644 index 0000000000000..87e003adaa05a --- /dev/null +++ b/.agents/skills/test-the-docs/sandbox/Dockerfile @@ -0,0 +1,34 @@ +# Runner for /test-the-docs: executes MDX fences inside the container. +FROM node:22-bookworm-slim + +ARG TARGETARCH +ARG SUPABASE_CLI_VERSION=2.39.2 + +RUN apt-get update && apt-get install -y --no-install-recommends \ + ca-certificates \ + curl \ + postgresql-client \ + && rm -rf /var/lib/apt/lists/* + +# Docker CLI only (daemon is DinD over TCP for stack profile) +COPY --from=docker:27-cli /usr/local/bin/docker /usr/local/bin/docker + +RUN set -eux; \ + arch="${TARGETARCH}"; \ + case "${arch}" in \ + amd64) cli_arch=amd64 ;; \ + arm64) cli_arch=arm64 ;; \ + *) cli_arch=amd64 ;; \ + esac; \ + curl -fsSL "https://github.com/supabase/cli/releases/download/v${SUPABASE_CLI_VERSION}/supabase_linux_${cli_arch}.tar.gz" \ + | tar -xz -C /usr/local/bin supabase; \ + chmod +x /usr/local/bin/supabase; \ + supabase --version + +RUN useradd --create-home --uid 1001 --shell /bin/bash runner \ + && mkdir -p /work /output /examples \ + && chown -R runner:runner /work /output /examples + +USER runner +WORKDIR /work +CMD ["bash"] diff --git a/.agents/skills/test-the-docs/sandbox/compose.yaml b/.agents/skills/test-the-docs/sandbox/compose.yaml new file mode 100644 index 0000000000000..00d24f3b73c74 --- /dev/null +++ b/.agents/skills/test-the-docs/sandbox/compose.yaml @@ -0,0 +1,81 @@ +# Disposable compose project for /test-the-docs. +# Host only starts/stops this project; MDX fences run inside the runner. +# +# Profiles: +# stack — privileged DinD + runner sharing DinD network (supabase start uses 127.0.0.1) +# examples — runner only; copies /examples into /work/example for npm install (no DinD) + +services: + dind: + image: docker:27-dind + privileged: true + environment: + DOCKER_TLS_CERTDIR: '' + command: ['dockerd', '--host=tcp://0.0.0.0:2375', '--host=unix:///var/run/docker.sock'] + healthcheck: + test: ['CMD', 'docker', 'info'] + interval: 2s + timeout: 5s + retries: 30 + start_period: 5s + profiles: + - stack + + runner: + build: + context: . + dockerfile: Dockerfile + working_dir: /work + user: '1001:1001' + environment: + TTD_IN_CONTAINER: '1' + command: ['sleep', 'infinity'] + volumes: + - type: bind + source: ${TTD_WORK_DIR:?set TTD_WORK_DIR} + target: /work + - type: bind + source: ${TTD_OUTPUT_DIR:?set TTD_OUTPUT_DIR} + target: /output + - type: bind + source: ${TTD_EXAMPLE_DIR:-./.empty} + target: /examples + read_only: true + networks: + - ttd + profiles: + - examples + + runner-stack: + build: + context: . + dockerfile: Dockerfile + working_dir: /work + user: '1001:1001' + # Share DinD's network namespace so supabase healthchecks on 127.0.0.1 succeed + network_mode: 'service:dind' + environment: + TTD_IN_CONTAINER: '1' + DOCKER_HOST: tcp://127.0.0.1:2375 + command: ['sleep', 'infinity'] + volumes: + - type: bind + source: ${TTD_WORK_DIR:?set TTD_WORK_DIR} + target: /work + - type: bind + source: ${TTD_OUTPUT_DIR:?set TTD_OUTPUT_DIR} + target: /output + - type: bind + source: ${TTD_EXAMPLE_DIR:-./.empty} + target: /examples + read_only: true + depends_on: + dind: + condition: service_healthy + profiles: + - stack + +networks: + ttd: + driver: bridge + name: ${TTD_NETWORK_NAME:-ttd-sandbox} diff --git a/.agents/skills/test-the-docs/sandbox/run.sh b/.agents/skills/test-the-docs/sandbox/run.sh new file mode 100755 index 0000000000000..85fd7c235cbce --- /dev/null +++ b/.agents/skills/test-the-docs/sandbox/run.sh @@ -0,0 +1,189 @@ +#!/usr/bin/env bash +# Host-side lifecycle for /test-the-docs sandbox. +# Starts a disposable compose project and execs fences inside the runner container. +# Usage: +# eval "$(./run.sh env)" # export TTD_* for the session +# ./run.sh up-stack # DinD + runner; supabase init/start in /work +# ./run.sh up-examples # runner only (no DinD); example-app builds in /work/example +# ./run.sh exec -- # run a command in the active runner +# ./run.sh exec-timeout 60 -- +# ./run.sh down # compose down -v and remove work/output dirs created by this script +set -euo pipefail + +SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" +COMPOSE_FILE="${SCRIPT_DIR}/compose.yaml" + +die() { + echo "error: $*" >&2 + exit 1 +} + +require_host_prereqs() { + if [[ "$(id -u)" = "0" ]]; then + die "refuse to run as root on the host" + fi + command -v docker >/dev/null || die "docker not found — install Docker Desktop" + docker info >/dev/null 2>&1 || die "Docker is not running — start Docker Desktop" + docker compose version >/dev/null 2>&1 || die "docker compose not available" +} + +compose() { + docker compose -p "${TTD_PROJECT_NAME}" -f "${COMPOSE_FILE}" "$@" +} + +runner_service() { + case "${TTD_PROFILE:-}" in + stack) echo runner-stack ;; + examples) echo runner ;; + *) die "TTD_PROFILE unset; run up-stack or up-examples first" ;; + esac +} + +ensure_state_dir() { + mkdir -p "${SCRIPT_DIR}/.state" +} + +write_env_file() { + ensure_state_dir + cat >"${SCRIPT_DIR}/.state/current.env" </dev/null 2>&1; then + break + fi + sleep 1 + done + docker info >/dev/null + cd /work + if [[ ! -f supabase/config.toml ]]; then + printf 'n\nn\n' | supabase init + fi + supabase start + ' + echo "sandbox ready: project=${TTD_PROJECT_NAME} work=${TTD_WORK_DIR} profile=stack (DinD)" >&2 +} + +cmd_up_examples() { + prepare_exports + export TTD_PROFILE=examples + write_env_file + compose --profile examples build runner + compose --profile examples up -d --remove-orphans runner + # Copy read-only mount into writable /work so npm can install without mutating the repo + compose --profile examples exec -T runner \ + bash -lc 'rm -rf /work/example && mkdir -p /work/example && cp -a /examples/. /work/example/' + echo "sandbox ready: project=${TTD_PROJECT_NAME} work=${TTD_WORK_DIR} profile=examples (build in /work/example)" >&2 +} + +cmd_exec() { + load_env_file + local svc + svc="$(runner_service)" + compose --profile "${TTD_PROFILE}" exec -T "${svc}" "$@" +} + +cmd_exec_timeout() { + load_env_file + local secs="$1" + shift + if [[ "${1:-}" == "--" ]]; then + shift + fi + local svc + svc="$(runner_service)" + compose --profile "${TTD_PROFILE}" exec -T "${svc}" \ + timeout --foreground --signal=TERM --kill-after=5s "${secs}s" "$@" +} + +cmd_down() { + if [[ -f "${SCRIPT_DIR}/.state/current.env" ]]; then + # shellcheck disable=SC1091 + source "${SCRIPT_DIR}/.state/current.env" + else + die "no active sandbox state" + fi + if [[ "${TTD_PROFILE:-}" == "stack" ]]; then + compose --profile stack exec -T runner-stack bash -lc 'cd /work && supabase stop 2>/dev/null || true' 2>/dev/null || true + fi + compose --profile "${TTD_PROFILE:-stack}" down -v --remove-orphans 2>/dev/null || true + rm -rf "${TTD_WORK_DIR:-}" "${TTD_OUTPUT_DIR:-}" 2>/dev/null || true + rm -f "${SCRIPT_DIR}/.state/current.env" + echo "sandbox torn down: ${TTD_PROJECT_NAME:-unknown}" >&2 +} + +usage() { + sed -n '2,10p' "$0" | sed 's/^# //; s/^#//' +} + +main() { + local cmd="${1:-}" + shift || true + case "${cmd}" in + env) cmd_env "$@" ;; + up-stack) cmd_up_stack "$@" ;; + up-examples) cmd_up_examples "$@" ;; + exec) + if [[ "${1:-}" == "--" ]]; then shift; fi + cmd_exec "$@" + ;; + exec-timeout) cmd_exec_timeout "$@" ;; + down) cmd_down "$@" ;; + -h | --help | help | "") usage ;; + *) die "unknown command: ${cmd}" ;; + esac +} + +main "$@" diff --git a/.agents/skills/write-the-docs/SKILL.md b/.agents/skills/write-the-docs/SKILL.md index 8380bd4c03e3c..80b892e4feeee 100644 --- a/.agents/skills/write-the-docs/SKILL.md +++ b/.agents/skills/write-the-docs/SKILL.md @@ -28,7 +28,7 @@ Four inputs, read in this sequence (sequence, not priority; Linear remains the p 1. **Style guide — voice/terminology reference.** Start with [`apps/docs/CONTRIBUTING.md`](../../../apps/docs/CONTRIBUTING.md) and [`apps/docs/WORD_LIST.md`](../../../apps/docs/WORD_LIST.md) for voice, structure, and terminology. If those don't cover the case, fall back to the nearest comparable existing page under `apps/docs/content/` and say explicitly: _"no dedicated style guide yet — following the precedent of ``."_ See [reference/style-fallback.md](reference/style-fallback.md). 2. **Linear — the ticket and its product context.** Linear is an internal Supabase tool: preferred when available, not required for open-source contributors. When a Linear issue is available, pull it, then its parent project/initiative description too (PRD, PRFAQ, RFC, or initiative narrative) and any PM comments. Product framing/positioning language usually lives one level up from the ticket, in the parent project or initiative description rather than the ticket body. Distinguish scope the ticket actually commits to from aspirational language in the PRD. If there is no Linear issue and no prior Frame/Shape product-intent output, stop drafting: ask internal authors for a Linear URL, otherwise hand off to [`pm-the-docs`](../pm-the-docs/SKILL.md) (Frame) and [`ask-the-docs`](../ask-the-docs/SKILL.md) when Shape/IA is unsettled. Resume only after product intent exists — never invent positioning, and never run Frame/Shape inside this Draft skill. -3. **Code.** Read the actual implementation before writing a single behavior claim — the PRD describes intent, the code describes what shipped. Check the Linear issue/project first for a linked `supabase/supabase` PR — its diff and description are the most precise "what actually shipped" source, more precise than a general codebase read. If no PR is linked, locate the feature directly in `supabase/supabase` (or the product's own repo), and apply [`ask-the-docs`](../ask-the-docs/SKILL.md)'s reuse/minimalism lens: understand what exists before describing it. If code and PRD disagree, the code wins for behavior claims — flag the mismatch rather than silently picking one. +3. **Code.** Read the actual implementation before writing a single behavior claim — the PRD describes intent, the code describes what shipped. Check the Linear issue/project first for a linked `supabase/supabase` PR — its diff and description are the most precise "what actually shipped" source, more precise than a general codebase read. If no PR is linked, locate the feature directly in `supabase/supabase` (or the product's own repo), and apply [`ask-the-docs`](../ask-the-docs/SKILL.md)'s reuse/minimalism lens: understand what exists before describing it. When behavior spans services (CLI, Auth, migrations, platform, …), follow [`pm-the-docs`](../pm-the-docs/SKILL.md) → [universe-lookup](../pm-the-docs/reference/universe-lookup.md) **capability gate** (universe when accessible, else OSS public search / linked repos — not `ask-the-docs`). If code and PRD disagree, the code wins for behavior claims — flag the mismatch rather than silently picking one. 4. **Whatever else the author supplies.** Screenshots, example projects, related pages, Slack threads, a specific voice sample. Screenshots are for more than general context — use them to verify the _exact_ button/menu/field labels before writing instructional steps that reference them; a mismatched UI label is one of the easiest, most avoidable errors in a draft. Ask for these when the feature's user-facing shape is still unclear after 1–3, rather than guessing. Summarize all four back to the requester before drafting: what's confirmed, what's product intent vs. shipped behavior, what's still a gap. Stop and ask if a real gap would change the draft's structure or scope. @@ -67,6 +67,7 @@ Before handing off, confirm: - [ ] Content type confirmed as Guide/Troubleshooting (not something that belongs in generated Reference instead) - [ ] Nav placement and nav enablement both wired, not just the placement - [ ] Internal links resolve; first-use of new terms/acronyms is defined +- [ ] If the draft has procedural snippets (CLI, SQL, client code, or example apps), **offered** to run [`test-the-docs`](../test-the-docs/SKILL.md) (optional; Docker Compose sandbox — stack profile for DB/API, examples profile for `example-app`) - [ ] Future promises minimized where possible (timeless documentation principle) - [ ] No unnecessary redundancy (same point restated multiple ways) - [ ] Single-item lists avoided unless there's a specific reason @@ -86,6 +87,8 @@ Re-read [`apps/docs/CONTRIBUTING.md`](../../../apps/docs/CONTRIBUTING.md) and [` This skill stops at a reviewable draft. It does not open worktrees or PRs itself: +- **Offer** [`test-the-docs`](../test-the-docs/SKILL.md) when the draft includes runnable procedural snippets. Ask before starting verification. Gate prerequisites **per artifact class** (Docker Compose stack profile for DB/API artifacts; examples profile / Node in-runner for `example-app`). If declined, or a required prerequisite for that class is missing, record `deferred` for those artifacts only and continue. When accepted, attach the verification report to the PR body / self-review note. +- Then run [`review-the-docs`](../review-the-docs/SKILL.md) local self-review (lint/build/classify). - Hand off to [`create-pull-request`](https://github.com/supabase/docs-agent-skills/blob/main/.claude/skills/create-pull-request/SKILL.md) (and [`work-linear-issue`](https://github.com/supabase/docs-agent-skills/blob/main/.claude/skills/work-linear-issue/SKILL.md) if the ticket needs a full worktree+PR flow) for the actual PR mechanics. Carry the Phase 1/2 flagged-assumptions list forward explicitly into that handoff — it belongs in the PR description (e.g. a "needs review" section) so a reviewer sees it, not just as an inline comment buried in the draft. - If the feature is UI-driven and the PR will need screenshots/GIFs, flag [`proof-it-works`](https://github.com/supabase/docs-agent-skills/blob/main/.claude/skills/proof-it-works/SKILL.md) as the next step rather than capturing evidence here. - Before opening the PR, run [`review-the-docs`](../review-the-docs/SKILL.md) local self-review: `pnpm lint:mdx`, `pnpm build:guides-markdown` where applicable, and anchor checks per [reference/drafting-mechanics.md](reference/drafting-mechanics.md). @@ -98,6 +101,8 @@ This skill stops at a reviewable draft. It does not open worktrees or PRs itself - Content-type gate detail: [reference/content-type-gate.md](reference/content-type-gate.md) - Existing-page restructure/clarity: [`edit-the-docs`](../edit-the-docs/SKILL.md) - "Write the docs" checklist (Draft stage): [`pm-the-docs`](../pm-the-docs/SKILL.md)'s [reference/write-the-docs-checklist.md](../pm-the-docs/reference/write-the-docs-checklist.md) +- Cross-repo product lookup: [`pm-the-docs`](../pm-the-docs/SKILL.md) → [universe-lookup](../pm-the-docs/reference/universe-lookup.md) +- Runnable verification: [`test-the-docs`](../test-the-docs/SKILL.md) - Docs-app architecture/placement: [`ask-the-docs`](../ask-the-docs/SKILL.md), [`audit-docs-ia`](https://github.com/supabase/docs-agent-skills/blob/main/.claude/skills/audit-docs-ia/SKILL.md) - PR mechanics: [`create-pull-request`](https://github.com/supabase/docs-agent-skills/blob/main/.claude/skills/create-pull-request/SKILL.md), [`work-linear-issue`](https://github.com/supabase/docs-agent-skills/blob/main/.claude/skills/work-linear-issue/SKILL.md) - Screenshots/proof: [`proof-it-works`](https://github.com/supabase/docs-agent-skills/blob/main/.claude/skills/proof-it-works/SKILL.md) diff --git a/apps/docs/CONTRIBUTING.md b/apps/docs/CONTRIBUTING.md index 42e465763e6fe..8ad5a85dd76a4 100644 --- a/apps/docs/CONTRIBUTING.md +++ b/apps/docs/CONTRIBUTING.md @@ -23,14 +23,15 @@ To make docs as clear as possible: If you're using an AI coding agent (Claude Code, Codex, or anything else that reads `.agents/skills/`), this repo ships skills that back the [Write the docs](../../.agents/skills/pm-the-docs/reference/write-the-docs-checklist.md) authoring checklist. -Ask your agent for a skill by name (`write-the-docs`, `edit-the-docs`, `ask-the-docs`, `pm-the-docs`, `review-the-docs`); in Claude Code these are also available as `/name` slash commands. +Ask your agent for a skill by name (`pm-the-docs`, `ask-the-docs`, `write-the-docs`, `edit-the-docs`, `test-the-docs`, `review-the-docs`); in Claude Code these are also available as `/name` slash commands. | Skill | Checklist stage | Use for | | --- | --- | --- | -| [`pm-the-docs`](../../.agents/skills/pm-the-docs/SKILL.md) | Frame / Shape | Audience, product-stage, and cross-cutting scope calls | +| [`pm-the-docs`](../../.agents/skills/pm-the-docs/SKILL.md) | Frame / Shape | Audience, product-stage, and cross-cutting scope calls (universe when you have Supabase org access, else OSS path) | | [`ask-the-docs`](../../.agents/skills/ask-the-docs/SKILL.md) | Frame / Shape | `apps/docs` architecture, IA placement, and where content lives | | [`write-the-docs`](../../.agents/skills/write-the-docs/SKILL.md) | Draft | Drafting net-new content grounded in the code | | [`edit-the-docs`](../../.agents/skills/edit-the-docs/SKILL.md) | Edit | Restructure and improve existing pages | +| [`test-the-docs`](../../.agents/skills/test-the-docs/SKILL.md) | Draft / Self-review | Execute docs snippets in a Docker-isolated local stack; verification report | | [`review-the-docs`](../../.agents/skills/review-the-docs/SKILL.md) | Self-review / PR review | Checking a draft and PR triage/verification | The canonical files live in `.agents/skills/`; `.claude/skills` is a Git symlink to that directory so Claude Code discovers them too. From 8a41a74e36d7bd02a359ceeb01dd3ebc4835add7 Mon Sep 17 00:00:00 2001 From: Nik Richers Date: Thu, 3 Sep 2026 20:13:09 -0700 Subject: [PATCH 3/9] fix(www): prevent mobile blog layout overflow (#49983) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ## I have read the CONTRIBUTING.md file. YES ## What kind of change does this PR introduce? This PR fixes a mobile layout bug on blog posts where long unwrapped URLs made the article column wider than its flex parent. With `justify-center`, that overflow centered the column and clipped content on both sides. It also hardens the reading progress bar so it no longer uses `100vw`, matching the overflow-safe pattern already used on changelog prose. ## What is the current behavior? - On mobile Safari, `/blog/are-supabase-docs-agent-friendly` shifts left with empty space on the right and clipped title/body text - A raw long URL in a blockquote (`row-level-security.md`) expands the flex column past the parent width - The reading progress fill uses `w-screen` (`100vw`) with a negative `translate3d`, which can widen layout outside the blog `overflow-x-clip` shell ## What is the new behavior? - Blog main column uses `min-w-0 w-full` so flex children cannot outgrow the parent - Blog prose uses `wrap-break-word` (same as changelog) so long URLs wrap - Scroll progress bar uses parent width plus `overflow-hidden` instead of `w-screen` ## Additional context - Branch: `fix-docs-agents-blog-post-on-mobile` - Files: `apps/www/components/Blog/BlogPostRenderer.tsx`, `apps/www/components/ScrollProgress.tsx` - Verification: | Check | Result | | --- | --- | | Production at 390px: title `h1` left ≈ -42 (shifted) | pass (reproduced) | | Preview at 390px: title `h1` left = 24, right = 366 | pass | | `scrollWidth === clientWidth` on preview | pass | | Progress bar still fills on scroll | pass | | Hero image still `hidden lg:block` (unchanged) | pass | ### Proof: mobile blog no longer shifts left **Verified:** production before vs PR www preview after, both captured at CSS viewport 390×844 via `page.setViewport` (not Chrome `--window-size`) | [Before (production)](https://supabase.com/blog/are-supabase-docs-agent-friendly) | [After (PR preview)](https://zone-www-dot-com-git-fix-docs-agents-blog-post-4e52df-supabase.vercel.app/blog/are-supabase-docs-agent-friendly) | | --- | --- | | ![Before](https://moijyfpvgnmgoxvwcikq.supabase.co/storage/v1/object/public/pr-proof/supabase/supabase/pr49983/mobile-blog-overflow-before-219e3df5.png) | ![After](https://moijyfpvgnmgoxvwcikq.supabase.co/storage/v1/object/public/pr-proof/supabase/supabase/pr49983/mobile-blog-overflow-after-85f7751b.png) | - **Before:** https://supabase.com/blog/are-supabase-docs-agent-friendly - **After:** https://zone-www-dot-com-git-fix-docs-agents-blog-post-4e52df-supabase.vercel.app/blog/are-supabase-docs-agent-friendly ### Test plan - [ ] Open [production](https://supabase.com/blog/are-supabase-docs-agent-friendly) at ~390px and confirm the clipped/shifted layout - [ ] Open the [PR www preview](https://zone-www-dot-com-git-fix-docs-agents-blog-post-4e52df-supabase.vercel.app/blog/are-supabase-docs-agent-friendly) at ~390px - [ ] Confirm title, authors, and body are fully visible with no empty strip on the right - [ ] Confirm `document.documentElement.scrollWidth === document.documentElement.clientWidth` - [ ] Scroll and confirm the green reading progress bar still fills - [ ] Spot-check another blog post without a raw long URL for no layout regression Co-authored-by: Nik Richers --- apps/www/components/Blog/BlogPostRenderer.tsx | 4 ++-- apps/www/components/ScrollProgress.tsx | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/apps/www/components/Blog/BlogPostRenderer.tsx b/apps/www/components/Blog/BlogPostRenderer.tsx index 0e838af82136a..f923dd1ac6a79 100644 --- a/apps/www/components/Blog/BlogPostRenderer.tsx +++ b/apps/www/components/Blog/BlogPostRenderer.tsx @@ -109,7 +109,7 @@ const BlogPostRenderer = async ({ */}
    {/* Main container — indented 1 col at lg, alongside back button at xl */} -
    +
    {/* Article header — spans the full main container width */}
    @@ -202,7 +202,7 @@ const BlogPostRenderer = async ({ )}
    -
    +
    {blogMetaData.youtubeHero ? (