mirror of
https://github.com/supabase/supabase.git
synced 2026-09-22 13:37:53 +08:00
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 -->
95 lines
2.6 KiB
Plaintext
95 lines
2.6 KiB
Plaintext
---
|
|
id: 'auth-legacy-jwt'
|
|
title: 'Integrating With Supabase Auth'
|
|
description: 'Supabase Edge Functions and Auth.'
|
|
subtitle: 'Integrate Supabase Auth with Edge Functions'
|
|
---
|
|
|
|
Edge Functions work with [Supabase Auth](/docs/guides/auth).
|
|
|
|
This allows you to:
|
|
|
|
- Automatically identify users through Legacy JWT tokens
|
|
- Enforce Row Level Security policies
|
|
- Integrate with your existing auth flow
|
|
|
|
## Setting up auth context
|
|
|
|
When a user makes a request to an Edge Function, you can use the `Authorization` header to set the Auth context in the Supabase client and enforce Row Level Security policies.
|
|
|
|
```js
|
|
import { createClient } from 'npm:@supabase/supabase-js@2'
|
|
|
|
Deno.serve(async (req: Request) => {
|
|
const supabaseClient = createClient(
|
|
Deno.env.get('SUPABASE_URL') ?? '',
|
|
Deno.env.get('SUPABASE_ANON_KEY') ?? '',
|
|
// Create client with Auth context of the user that called the function.
|
|
// This way your row-level-security (RLS) policies are applied.
|
|
{
|
|
global: {
|
|
headers: { Authorization: req.headers.get('Authorization')! },
|
|
},
|
|
}
|
|
);
|
|
|
|
//...
|
|
})
|
|
```
|
|
|
|
<Admonition type="note">
|
|
|
|
This context setting happens in the `Deno.serve()` callback argument, so that the `Authorization` header is set for each individual request scope.
|
|
|
|
</Admonition>
|
|
|
|
---
|
|
|
|
## 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 signed-in user.
|
|
|
|
```js
|
|
Deno.serve(async (req: Request) => {
|
|
// ...
|
|
const authHeader = req.headers.get('Authorization')!
|
|
const token = authHeader.replace('Bearer ', '')
|
|
const { data } = await supabaseClient.auth.getUser(token)
|
|
// ...
|
|
})
|
|
```
|
|
|
|
---
|
|
|
|
## Row Level Security
|
|
|
|
After initializing a Supabase client with the Auth context, all queries will be executed with the context of the user. For database queries, this means [Row Level Security](/docs/guides/database/postgres/row-level-security) will be enforced.
|
|
|
|
```js
|
|
import { createClient } from 'npm:@supabase/supabase-js@2'
|
|
|
|
Deno.serve(async (req: Request) => {
|
|
// ...
|
|
// This query respects RLS - users only see rows they have access to
|
|
const { data, error } = await supabaseClient.from('profiles').select('*');
|
|
|
|
if (error) {
|
|
return new Response('Database error', { status: 500 })
|
|
}
|
|
|
|
// ...
|
|
})
|
|
```
|
|
|
|
---
|
|
|
|
## Example
|
|
|
|
See the full [example on GitHub](https://github.com/supabase/supabase/blob/master/examples/edge-functions/supabase/functions/select-from-table-with-auth-rls/index.ts).
|
|
|
|
<$CodeSample
|
|
path="/edge-functions/supabase/functions/select-from-table-with-auth-rls/index.ts"
|
|
title="Select from table with auth RLS"
|
|
language="typescript"
|
|
/>
|