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] 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 4709faa48fe..2e8fe0b71c8 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 4a7cdfcdb07..8d8909cdb50 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 70d24d18310..54ebaab7968 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 40ca46ba1d3..c67490d0ad6 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 8fb46f2b22d..e3ee4af18cc 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 0cfcc6e6af1..314cbb241e8 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 8e3b42acbcb..1ba0492e846 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 64762769bc4..72462efef74 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 dc788a70025..842f94d5013 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 3665526c40c..053c76df6ae 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 9d74ea36edb..9a57fa22200 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 d3d764d45f5..5e00867dd86 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 97c8c160899..73c5f0bc67b 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 aeb34c9c64e..6d6b2b44d2d 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 003b453f30a..bb941179bad 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 abc0bc9dd0f..ad8dc478e83 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 1a0c97bdde1..d90c6b96fd7 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 2bf410157f7..8e838878353 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 2660dea758a..53cf98f68b5 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 7ff2e248828..75b4e546601 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 c839c206fee..9a4d0ccc221 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 fcb98df2791..0bc629faf7b 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 eded448adc3..1e5eea02e55 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 855391dca71..f67a2951508 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 479ff4955a5..428aaeb26f1 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 7700b558b68..9b48256870a 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 f624e8d03ec..a8ac9181ab4 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 4646c475d56..dda461e87e2 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 2a4083b87a2..a7e2c6cc13f 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 6433597e583..cdcb87370fe 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 78b8d9b0569..e98435a57ac 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 5d0dd8a3b60..1c02a4ca4db 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 45c9dc8a3b2..a482b255190 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 1c3a0864d31..1148249d6c9 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 0ad2d0c0eff..60e40de3b4b 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 0fc8f870b95..26cb649347d 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 41c5d175039..7808b3b18c9 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 72f19204c05..7b9dd624f4c 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 69127466998..2bb5a5f62d6 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 68fdf896297..eeb9812a161 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 a7ba70a4806..75b1eaeca92 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 329607922c2..69324662c1b 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 9b98eb9b869..5bca2ba1c46 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 9b11d1ec6d6..91eb4ff3e23 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 b573c41d5d1..cb67510d501 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 cce73dd2790..fcf5b1d129b 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 9ca784530e1..57fdfd03fb4 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 1d6921561d5..0d9d6d1f293 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 9d0f220885f..6cc4ac7a1f9 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 c65739aed50..0f138d95a2e 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 64fbbdbc2b1..3f6ef307344 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 19ea149237c..f5bf9d39443 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 a1bec2c404b..0846bcdea8f 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 fac23b6ec1e..310e4c69efb 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 fcf2908a826..a9af115c05a 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 877c240120d..8bbabde0dc5 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 9fd1f84564e..8060eeec0a6 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 4541d2fc44b..10c7d8282ae 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 43c27e7c434..e4d66f541c2 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 cb0774b4cd2..9f482e115b6 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 62b3582985c..536167c2e30 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 064a8c2c732..c95e2dd22b8 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 278ce203502..8107b1befb4 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 2b8e65cf305..b9d3c1d6b20 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 45057d067c1..b3e783bfe71 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 3013377e7a1..a76d052cde5 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 59ef3015545..eba4ea6cf70 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 ebbf6cb9030..d1acbc83519 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 404648f57b0..1611efb5a24 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 1f995d36f80..afed6fcdfc0 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 c294cbfbbb6..90a26800959 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 c14b60cf62a..eb86f0ac58c 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 b99743659b0..531e905ff79 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 417eaaf9f80..d7746c5fff1 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 ad4399f9e2c..3e012208c58 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 12a84f98cad..82d4bbdaab7 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 647a5c880cb..6579d26323d 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 036416e8746..99209b9e86d 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 e555d0b6622..42c3ed84811 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 24a66b899f6..68eabc48da2 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 73907c736ea..0bb1501bdde 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 1e12f8e6ca2..e3f678a412f 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 dbd73ffa400..bd215b392aa 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 5a38ace3123..e6415d7258d 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 d460dcb6232..fd9a099c51e 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 1427441a215..7a3ec0bcc88 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 e1ac45325ed..08e22a1eb07 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 726596f60bc..f911eef9f05 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 88115781337..d623c5fe50a 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 913f534ed24..db6f954bdd3 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 2e6d6c65ed3..6cc84c067dc 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 1b887d93a7d..e70cc5997bb 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 d28c1fda108..9702c7096e5 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 b67b0fab734..44bd9031357 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 7e5f49b3a53..5e5d84adc6f 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 8e51b7d7940..d0fba4986bb 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 7877fc94f31..e68fa60acac 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 8a890895fe6..79b7e9d3e09 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 e6ed64b34c0..f25f5e71220 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 6b17aced1e4..ca849c63247 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 331c94c5f13..66e4872deb9 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 99eaa048419..071b14df568 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 e0514267ef9..15054f368e0 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 844bdbf6d52..1725badee7e 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 f3719ab5785..03c102d3628 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 fe267d37111..23235fb6c1f 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 f3671ceb1ae..509df827733 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 ab1ba004251..69af4b60ae3 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 1bf0a040dd7..6c0a612d95a 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 a1b21c70f2b..497b8f6d07d 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 2de91f081eb..b1f0825fe2d 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 09134ade3ae..03ea3bd0950 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 a5b868a0c6a..dd5e3078e4d 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 709d4c13294..2df29e61371 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 cb46b3999c7..8fba01c8673 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 14946e10246..d11dc4343e6 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 e8e869ea71b..4dd30b2de6e 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 a42bb368f45..5681c7641f3 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 be7d643535d..c5dd7db3a28 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 5b77ff8d10e..36e420ec033 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 6251a84fa52..e7c455a60ee 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 132a3fd12b5..71a11780711 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