mirror of
https://github.com/supabase/supabase.git
synced 2026-10-06 18:05:11 +03:00
Danny White
24be387cdb
## 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) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## 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.” <!-- end of auto-generated comment: release notes by coderabbit.ai -->
35 lines
3.2 KiB
Plaintext
35 lines
3.2 KiB
Plaintext
---
|
|
id: 'auth-general-configuration'
|
|
title: 'General configuration'
|
|
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 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.
|
|
- [Email Templates](/dashboard/project/_/auth/templates) to configure what emails your users receive.
|
|
- [Custom SMTP](/dashboard/project/_/auth/smtp) to configure how emails are sent.
|
|
- [Multi-Factor](/dashboard/project/_/auth/mfa) to require users to provide additional verification factors to authenticate.
|
|
- [URL Configuration](/dashboard/project/_/auth/url-configuration) to configure site URL and redirect URLs for authentication. Read more [in the redirect URLs documentation](/docs/guides/auth/redirect-urls).
|
|
- [Attack Protection](/dashboard/project/_/auth/protection) to configure security settings to protect your project from attacks.
|
|
- [Auth Hooks (BETA)](/dashboard/project/_/auth/auth-hooks) to use Postgres functions or HTTP endpoints to customize the behavior of Supabase Auth to meet your needs.
|
|
- [Audit Logs (BETA)](/dashboard/project/_/auth/audit-logs) to track and monitor auth events in your project.
|
|
- [Performance](/dashboard/project/_/auth/performance) to configure and optimize authentication server settings.
|
|
|
|
Supabase Auth provides these [general configuration options](/dashboard/project/_/auth/providers) to control user access to your application:
|
|
|
|
- **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 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. */}
|
|
|
|
- **Allow anonymous sign-ins**: Allow anonymous users to be created.
|
|
|
|
- **Allow manual linking**: Allow users to link their accounts manually.
|