mirror of
https://github.com/supabase/supabase.git
synced 2026-10-06 18:05:11 +03:00
## 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 -->
127 lines
4.0 KiB
Plaintext
127 lines
4.0 KiB
Plaintext
---
|
|
id: 'using-custom-schemas'
|
|
title: 'Using Custom Schemas'
|
|
description: 'You need additional steps to use custom database schemas with data APIs.'
|
|
---
|
|
|
|
By default, your database has a `public` schema which is automatically exposed on data APIs.
|
|
|
|
## Creating custom schemas
|
|
|
|
You can create your own custom schema/s by running the following SQL, substituting `myschema` with the name you want to use for your schema:
|
|
|
|
```sql
|
|
CREATE SCHEMA myschema;
|
|
```
|
|
|
|
## Exposing custom schemas
|
|
|
|
You can expose custom database schemas - to do so you need to follow these steps:
|
|
|
|
1. Go to [API settings](/dashboard/project/_/settings/api) and add your custom schema to "Exposed schemas".
|
|
2. Run the following SQL, substituting `myschema` with your schema name:
|
|
|
|
```sql
|
|
GRANT USAGE ON SCHEMA myschema TO anon, authenticated, service_role;
|
|
GRANT ALL ON ALL TABLES IN SCHEMA myschema TO anon, authenticated, service_role;
|
|
GRANT ALL ON ALL ROUTINES IN SCHEMA myschema TO anon, authenticated, service_role;
|
|
GRANT ALL ON ALL SEQUENCES IN SCHEMA myschema TO anon, authenticated, service_role;
|
|
ALTER DEFAULT PRIVILEGES FOR ROLE postgres IN SCHEMA myschema GRANT ALL ON TABLES TO anon, authenticated, service_role;
|
|
ALTER DEFAULT PRIVILEGES FOR ROLE postgres IN SCHEMA myschema GRANT ALL ON ROUTINES TO anon, authenticated, service_role;
|
|
ALTER DEFAULT PRIVILEGES FOR ROLE postgres IN SCHEMA myschema GRANT ALL ON SEQUENCES TO anon, authenticated, service_role;
|
|
```
|
|
|
|
Now you can access these schemas from data APIs:
|
|
|
|
<Tabs
|
|
scrollable
|
|
size="small"
|
|
type="underlined"
|
|
defaultActiveId="javascript"
|
|
queryGroup="language"
|
|
>
|
|
<TabPanel id="javascript" label="JavaScript">
|
|
|
|
```js
|
|
// Initialize the JS client
|
|
import { createClient } from '@supabase/supabase-js'
|
|
|
|
const supabase = createClient(SUPABASE_URL, SUPABASE_PUBLISHABLE_KEY, {
|
|
db: { schema: 'myschema' },
|
|
})
|
|
|
|
// Make a request
|
|
const { data: todos, error } = await supabase.from('todos').select('*')
|
|
|
|
// You can also change the target schema on a per-query basis
|
|
const { data: todos, error } = await supabase.schema('myschema').from('todos').select('*')
|
|
```
|
|
|
|
<Admonition type="note">
|
|
|
|
With generated `Database` types that include `public`, `createClient<Database>(...)` type-checks `db.schema` against `public` only, unless the schema name is also passed as the second generic: `createClient<Database, 'myschema'>(...)`. `supabase.schema('myschema').from(...)` infers its schema per call and needs no second generic. In both cases `myschema` has to be present in the generated `Database` type.
|
|
|
|
</Admonition>
|
|
|
|
</TabPanel>
|
|
<$Show if="sdk:dart">
|
|
<TabPanel id="dart" label="Dart">
|
|
```dart
|
|
// Initialize the Flutter client
|
|
await Supabase.initialize(
|
|
url: supabaseUrl,
|
|
publishableKey: publishableKey,
|
|
postgrestOptions: const PostgrestClientOptions(schema: 'myschema'),
|
|
);
|
|
final supabase = Supabase.instance.client;
|
|
|
|
// Make a request
|
|
final data = await supabase.from('todos').select();
|
|
|
|
// You can also change the target schema on a per-query basis
|
|
final data = await supabase.schema('myschema').from('todos').select();
|
|
|
|
````
|
|
</TabPanel>
|
|
</$Show>
|
|
<$Show if="sdk:csharp">
|
|
<TabPanel id="csharp" label="C#">
|
|
|
|
```c#
|
|
// Initialize the client with a custom schema
|
|
var supabase = new Supabase.Client(
|
|
SUPABASE_URL,
|
|
SUPABASE_PUBLISHABLE_KEY,
|
|
new SupabaseOptions { Schema = "myschema" }
|
|
);
|
|
await supabase.InitializeAsync();
|
|
|
|
// Make a request
|
|
var todos = await supabase.From<Todo>().Get();
|
|
```
|
|
|
|
</TabPanel>
|
|
</$Show>
|
|
<TabPanel id="curl" label="cURL">
|
|
|
|
```bash
|
|
# Append /rest/v1/ to your URL, and then use the table name as the route.
|
|
|
|
# for GET or HEAD request use Accept-Profile
|
|
curl '<SUPABASE_URL>/rest/v1/todos' \
|
|
-H "apikey: <SUPABASE_PUBLISHABLE_KEY>" \
|
|
-H "Authorization: Bearer <SUPABASE_PUBLISHABLE_KEY>" \
|
|
-H "Accept-Profile: myschema"
|
|
|
|
# for POST, PATCH, PUT and DELETE Request use Content-Profile
|
|
curl -X POST '<SUPABASE_URL>/rest/v1/todos' \
|
|
-H "apikey: <SUPABASE_PUBLISHABLE_KEY>" \
|
|
-H "Authorization: Bearer <SUPABASE_PUBLISHABLE_KEY>" \
|
|
-H "Content-Type: application/json" \
|
|
-H "Content-Profile: myschema" \
|
|
-d '{"column_name": "value"}'
|
|
````
|
|
|
|
</TabPanel>
|
|
</Tabs>
|