Codice supabase-js v2 funzionante per email e password, magic link, accesso OAuth, listener di sessione e logout, più policy di row level security che usano auth.uid().
Supabase Auth fa accedere le persone con email e password, magic link monouso, codici via telefono o provider OAuth come GitHub, tutto tramite l'oggetto supabase.auth di supabase-js. Ogni accesso produce una sessione il cui token arriva al tuo database, dove le policy di row level security confrontano auth.uid() con una colonna user_id per decidere cosa può leggere quella persona.
Metodi di accesso e la chiamata per ciascuno
Metodo
Chiamata supabase-js v2
Ideale per
Email e password
auth.signUp / auth.signInWithPassword
Account classici
Magic link
auth.signInWithOtp({ email })
Nessuna password da dimenticare
Codice via SMS o WhatsApp
auth.signInWithOtp({ phone })
Prodotti pensati per il mobile
Provider OAuth
auth.signInWithOAuth({ provider })
Accesso con un clic tramite un account esistente
Logout
auth.signOut()
Chiudere la sessione
L'autenticazione è la parte di un progetto Supabase che più spesso viene collegata male: l'accesso funziona, ma i dati sono completamente esposti oppure il server si fida di un cookie di cui non dovrebbe. Scegli un metodo qui sotto per ottenerne il codice, poi segui la sezione sulle policy così ogni persona vede solo le proprie righe.
Scegli un metodo di accesso nel selettore di codice e copia lo snippet nella tua app.
Attiva il provider corrispondente nella dashboard di Supabase e aggiungi l'indirizzo del tuo sito agli URL di reindirizzamento consentiti.
Ascolta gli eventi di autenticazione così la tua interfaccia si aggiorna quando qualcuno accede o esce.
Attiva la row level security su ogni tabella che contiene dati personali e aggiungi policy che usano auth.uid().
Con la conferma email attiva, signUp restituisce un utente ma una sessione null finché il link non viene cliccato, quindi mostra un messaggio controlla la tua casella invece di una dashboard.
Scrivi la funzione come (select auth.uid()) dentro le policy. Così Postgres può valutarla una volta per istruzione invece che una volta per riga.
auth.uid() è null per le richieste senza un utente autenticato, quindi una policy che lo confronta con user_id semplicemente non trova nulla per i visitatori anonimi.
Sul server non fidarti di getSession() letto dai cookie; chiama getUser() o getClaims() per verificare chi sta facendo la richiesta.
La chiave publishable (anon) è sicura nel browser perché le policy la limitano. Una chiave secret o service role salta la row level security e deve restare sul server.
Domande frequenti
Il magic link di Supabase è la stessa cosa dell'OTP?
Entrambi partono da signInWithOtp. Per l'email, il messaggio contiene un link quando il template usa l'URL di conferma e un codice quando usa il token. L'accesso via telefono supporta solo codici, via SMS o WhatsApp.
Come aggiungo l'accesso con Google o GitHub?
Attiva il provider nella dashboard con il client ID e il secret forniti da quel provider, poi chiama signInWithOAuth con il suo nome e un indirizzo redirectTo facoltativo. La persona torna sul tuo sito già autenticata.
Come so quando un utente accede o esce?
Registra onAuthStateChange. Segnala eventi tra cui INITIAL_SESSION, SIGNED_IN, SIGNED_OUT, TOKEN_REFRESHED, USER_UPDATED e PASSWORD_RECOVERY, e restituisce una subscription da cui annullare l'iscrizione quando il componente viene smontato.
Perché gli utenti autenticati non vedono nulla dopo che ho attivato la RLS?
Una volta attivata la row level security, una tabella nega tutto finché una policy non lo consente. Aggiungi una policy di select per il ruolo authenticated che confronti (select auth.uid()) con la colonna del proprietario.
Meglio Supabase Auth o Firebase Auth?
Entrambi coprono i metodi più comuni. La differenza più grande è il database sottostante; il nostro confronto Supabase vs Firebase analizza questa scelta nel dettaglio.
Sessioni e token
Dopo l'accesso, supabase-js salva un access token di breve durata e un refresh token, e rinnova automaticamente l'access token. Ogni query che fai tramite lo stesso client invia l'access token, ed è così che Postgres conosce l'ID dell'utente.
Nelle app con rendering lato server la sessione vive invece nei cookie. La guida all'autenticazione in Next.js su questo sito tratta quel collegamento, quindi questa pagina resta sulla libreria client e sulle regole del database.
La row level security è la vera serratura
Nascondere un pulsante nell'interfaccia non protegge i dati, perché chiunque può chiamare la tua API con la chiave pubblica. Le policy girano dentro Postgres a ogni richiesta, ed è per questo che sono il punto in cui si fa rispettare la proprietà dei dati.
Scrivi una policy per ogni azione. Una policy di select usa using, mentre insert richiede with check così nessuno può creare righe che appartengono a qualcun altro, e update di solito richiede entrambi.
Policy che usano auth.uid()
Ogni persona legge e scrive solo le proprie note
Eseguilo nell'editor SQL. Il valore predefinito compila user_id dal token, e with check impedisce a chiunque di inserire righe per un altro utente.
Email e password
Crea l'account, poi accedi. Con la conferma attiva, data.session è null finché il link nell'email non viene cliccato.
Magic link
Invia un'email il cui link fa accedere la persona e la porta all'indirizzo di reindirizzamento.
OAuth (GitHub)
Reindirizza al provider e ritorno. Prima attiva il provider e imposta le sue chiavi nella dashboard.
Listener di sessione e logout
Mantiene l'interfaccia allineata alla sessione e rimuove il listener quando hai finito.