[Logto](https://logto.io/) è un moderno fornitore di servizi di autenticazione che offre supporto per il login sicuro, completo e facile da usare per le applicazioni. Offre anche un'infinità di SDK e guide di integrazione per più framework e linguaggi di programmazione, permettendoti di integrare senza sforzo servizi di autenticazione di livello enterprise nella tua applicazione in pochi minuti. Questo articolo si concentra principalmente sui dettagli di come integrare Supabase con Logto. ## Basi di Supabase Supabase utilizza la [Sicurezza a Livello di Righe di Postgres](https://www.postgresql.org/docs/current/ddl-rowsecurity.html) per controllare i permessi di accesso ai dati. In termini semplici, creando politiche di Sicurezza a Livello di Riga per tabelle nel database, possiamo limitare e gestire chi può leggere, scrivere e aggiornare i dati in una tabella. Supponiamo che tu abbia una tabella chiamata "posts" nel tuo database, con il seguente contenuto: Tabella dei post

Il campo `user_id` nella tabella rappresenta l'utente a cui appartengono i dati di ogni post. Puoi limitare ogni utente ad accedere solo ai propri dati dei post basandoti sul campo `user_id`. Tuttavia, prima che ciò possa essere implementato, Supabase deve essere in grado di identificare l'utente corrente che accede al database. ### Aggiungi i dati dell'utente alle richieste di Supabase Grazie al supporto di Suibase per JWT, quando la nostra applicazione interagisce con Supabase, possiamo generare un JWT contenente i dati dell'utente utilizzando il segreto JWT fornito da Supabase. Successivamente usiamo questo JWT come intestazione di Autenticazione quando facciamo richieste. Alla ricezione della richiesta, Supabase verifica automaticamente la validità del JWT e consente l'accesso ai dati contenuti all'interno durante i processi successivi. Innanzitutto, possiamo ottenere il segreto JWT fornito da Supabase dalle “Impostazioni del Progetto” nella dashboard di Supabase: Pagina delle impostazioni API di Supabase

Pagina delle impostazioni API di Supabase

Quindi, quando utilizziamo l'SDK di Supabase per fare richieste a Supabase, utilizziamo questo segreto per generare il nostro JWT e allegarlo come intestazione di Autenticazione alla richiesta. (Si noti che questo processo avviene all'interno del servizio backend della tua applicazione e il segreto JWT non dovrebbe mai essere esposto a terzi). ```jsx import { createClient } from '@supabase/supabase-js'; import { sign } from 'jsonwebtoken'; /** * Nota: * Puoi trovare SUPABASE_URL, SUPABASE_ANON_KEY nello stesso luogo in cui trovi il Segreto JWT. */ const SUPABASE_URL = process.env.SUPABASE_URL; const SUPABASE_ANON_KEY = process.env.SUPABASE_ANON_KEY; const SUPABASE_JWT_SECRET = process.env.SUPABASE_JWT_SECRET; export const getSupabaseClient = (userId) => { const jwtPayload = { userId, }; const jwt = sign(jwtPayload, SUPABASE_JWT_SECRET, { expiresIn: '1h', // Solo per dimostrazione }); const client = createClient(SUPABASE_URL, SUPABASE_ANON_KEY, { global: { headers: { Authorization: `Bearer ${jwt}`, }, }, }); return client; }; ``` Successivamente, vai all'Editor SQL nella dashboard di Supabase e crea una funzione per recuperare l'userId trasportato dalla richiesta: Creare funzione per ottenere l'ID utente

Creare funzione per ottenere l'ID utente

Il codice utilizzato nell'immagine è il seguente: ```sql create or replace function auth.user_id() returns text as $$ select nullif(current_setting('request.jwt.claims', true)::json->>'userId', '')::text; $$ language sql stable; ``` Come mostra il codice, in Supabase puoi recuperare il payload del JWT che generiamo chiamando `request.jwt.claims`. Il campo `userId` all'interno del payload è il valore che abbiamo impostato. Con questa funzione, Supabase può determinare l'utente che sta attualmente accedendo al database. ### Creazione di una politica di Sicurezza a Livello di Riga Successivamente, possiamo creare una politica di Sicurezza a Livello di Riga per limitare ogni utente ad accedere solo ai propri dati dei post in base al campo `user_id` nella tabella dei post. 1. Vai alla pagina dell'Editor delle Tabelle nella dashboard di Supabase e seleziona la tabella dei post. 2. Clicca su "Aggiungi Politica RLS" in cima alla tabella. 3. Nella finestra di dialogo, clicca su "Crea politica". 4. Inserisci un Nome della Politica e scegli il comando di Politica SELECT. 5. Nel blocco `using` del codice qui sotto, inserisci: ```sql auth.user_id() = user_id ``` Crea politica RLS

Grazie a queste politiche, si ottiene il controllo dell'accesso ai dati all'interno di Supabase. Nelle applicazioni reali, creeresti varie politiche per limitare le azioni degli utenti come l'inserimento e la modifica dei dati. Tuttavia, ciò va oltre il campo di applicazione di questo articolo. Per ulteriori informazioni sulla Sicurezza a Livello di Riga (RLS), fai riferimento a [Proteggi i tuoi dati utilizzando la Sicurezza a Livello di Riga di Postgres](https://supabase.com/docs/guides/database/postgres/row-level-security). ### Processo di integrazione di base con Logto Come accennato in precedenza, poiché Supabase utilizza RLS per il suo controllo degli accessi, la chiave per integrare Logto (o qualsiasi altro servizio di autenticazione) risiede nell'ottenere l'id dell'utente autorizzato e inviarlo a Supabase. L'intero processo è illustrato nel diagramma sottostante: ```mermaid sequenceDiagram Participant U as Utente finale Participant Logto Participant B as Servizio backend dell'app Participant Supabase U->>Logto: Accedi con Logto Logto-->>U: `access_token` U->>B: Richiesta dati con `access_token` B->>B: Recupera `user_id` da `access_token` B->>B: Genera jwt tramite `user_id` & `Segreto JWT di Supabase` B->>Supabase: Richiesta dati con jwt Supabase-->>B: Dati restituiti B-->>U: Dati restituiti ``` Successivamente, spiegheremo come integrare Logto con Supabase basandoci su questo diagramma del processo. ## Integrazione con Logto Logto offre guide di integrazione per vari framework e linguaggi di programmazione. Generalmente, le app costruite con questi framework e linguaggi rientrano in categorie come app Native, SPA (app single-page), app web tradizionali e app M2M (machine-to-machine). Puoi visitare la pagina [Logto quick starts](https://docs.logto.io/quick-starts/) per integrare Logto nella tua applicazione in base allo stack tecnologico che stai utilizzando. Successivamente, segui le istruzioni qui sotto per integrare Logto nel tuo progetto in base al tipo di applicazione. ### App Native o SPA Sia le app native che le SPA vengono eseguite sul tuo dispositivo e le credenziali (access token) ottenute dopo l'accesso sono memorizzate localmente sul tuo dispositivo. Pertanto, quando integri la tua app con Supabase, devi interagire con Supabase tramite il servizio backend perché non puoi esporre informazioni sensibili (come il segreto JWT di Supabase) sul dispositivo di ogni utente. Supponiamo che tu stia costruendo la tua SPA utilizzando React e Express. Hai integrato con successo Logto nella tua applicazione seguendo la [Guida SDK React di Logto](https://docs.logto.io/quick-starts/react/) (puoi fare riferimento al codice nel nostro [esempio react](https://github.com/logto-io/js/tree/master/packages/react-sample)). Inoltre, hai aggiunto la validazione dell'access token di Logto sul tuo server backend secondo la documentazione [Proteggi la tua API con Node (Express)](https://docs.logto.io/docs/recipes/protect-your-api/node/). Successivamente, utilizzerai l'access token ottenuto da Logto per richiedere i dati dell'utente dal tuo server backend: ```jsx import { useLogto } from '@logto/react'; import { useState, useEffect } from 'react'; import PostList from './PostList'; const endpoint = ''; const resource = ''; function PostPage() { const { isAuthenticated, getAccessToken } = useLogto(); const [posts, setPosts] = useState(); useEffect(() => { const fetchPosts = async () => { const response = await fetch(endpoint, { headers: { Authorization: `Bearer ${await getAccessToken(resource)}`, }, }); setPosts(response.json()); }; if (isAuthenticated) { void fetchPosts(); } }, [isAuthenticated, getAccessToken]); return ; } export default PostPage; ``` Nel tuo server backend, hai già estratto l'id dell'utente registrato dall'access token utilizzando il middleware: ```jsx // auth-middleware.ts import { createRemoteJWKSet, jwtVerify } from 'jose'; //... export const verifyAuthFromRequest = async (ctx, next) => { // Estrai il token const token = extractBearerTokenFromHeaders(ctx.request.headers); const { payload } = await jwtVerify( token, // Il raw Bearer Token estratto dall'intestazione della richiesta createRemoteJWKSet(new URL('https:///oidc/jwks')), // genera un jwks utilizzando jwks_uri richiesto dal server Logto { // emittore previsto del token, dovrebbe essere emesso dal server Logto issuer: 'https:///oidc', // audience prevista del token, dovrebbe essere l'indicatore risorsa dell'API corrente audience: '', } ); // se stai usando RBAC assert(payload.scope.includes('some_scope')); // logica di payload personalizzata ctx.auth = { userId: payload.sub, }; return next(); }; ``` Ora, puoi usare il `getSupabaseClient` descritto sopra per allegare l'`userId` al JWT utilizzato nelle richieste successive a Supabase. In alternativa, puoi creare un middleware per creare un client Supabase per le richieste che necessitano di interagire con Supabase: ```jsx export const withSupabaseClient = async (ctx, next) => { ctx.supabase = getSupabaseClient(ctx.auth.userId); return next(); }; ``` Nel flusso di elaborazione successivo, puoi chiamare direttamente `ctx.supabase` per interagire con Supabase: ```jsx const fetchPosts = async (ctx) => { cosnt { data } = await ctx.supabase.from('posts').select('*'); return data; } ``` In questo codice, Supabase restituirà solo i dati dei post appartenenti all'utente corrente basati sulle politiche impostate in precedenza. ### App web tradizionale La principale differenza tra un'app web tradizionale e una Native app o SPA è che un'app web tradizionale rende e aggiorna le pagine solo sul server web. Pertanto, le credenziali degli utenti sono gestite direttamente dal server web, mentre nelle Native app e nelle SPA risiedono sul dispositivo dell'utente. Quando integri Logto con un'app web tradizionale in Supabase, puoi recuperare direttamente l'id dell'utente registrato dal backend. Prendendo come esempio un progetto Next.js, dopo aver integrato Logto nel tuo progetto seguendo la [Guida SDK di Next.js](https://docs.logto.io/quick-starts/next-app-router/), puoi utilizzare l'SDK di Logto per recuperare le informazioni dell'utente e costruire il corrispondente JWT per interagire con Supabase. ```jsx import { getLogtoContext } from '@logto/next-server-actions'; import { logtoConfig } from '@/logto'; import { getSupabaseClient } from '@/utils'; import PostList from './PostList'; export default async function PostPage() { const { cliams } = await getLogtoContext(logtoConfig); // Il valore `sub` in `cliams` è l'id dell'utente. const supabase = getSupabaseClient(cliams.sub); const { data: posts } = await supabase.from('posts').select('*'); return ; } ``` ### App machine-to-machine Il machine-to-machine (M2M) è spesso usato quando la tua app ha bisogno di comunicare direttamente con i server di risorse, come un servizio statico che recupera post giornalieri, ecc. Puoi utilizzare la guida [Machine-to-machine: Autenticazione con Logto](https://docs.logto.io/quick-starts/m2m/) per l'autenticazione delle app machine-to-machine. L'integrazione tra Supabase e le app machine-to-machine è simile a quella delle Native app e SPA (come descritto nella sezione "Native app o single-page app"). Coinvolge l'ottenimento di un access token da Logto e successivamente la sua validazione tramite un'API backend protetta. Tuttavia, è importante notare che le Native app e le SPA sono tipicamente progettate per gli utenti finali, quindi l'id utente ottenuto rappresenta l'utente stesso. Tuttavia, l'access token per le app machine-to-machine rappresenta l'applicazione stessa, e il campo `sub` nel payload dell'access token è il client id dell'app M2M, non un utente specifico. Pertanto, durante lo sviluppo, è fondamentale distinguere quali dati sono destinati alle app M2M. Inoltre, se vuoi che una specifica app M2M acceda a Supabase per conto dell'intero servizio per bypassare le restrizioni RLS, puoi usare il segreto `service_role` di Supabase per creare un client Supabase. È utile quando vuoi eseguire alcune attività amministrative o automatizzate che richiedono accesso a tutti i dati senza essere limitate dalle politiche di Sicurezza a Livello di Riga impostate per singoli utenti. Il segreto `service_role` può essere trovato nella stessa pagina del segreto JWT: Segreto del ruolo di servizio

Quando crei un client Supabase, usa il segreto `service_role`. Questo client potrà accedere a tutti i dati nel database: ```jsx import { createClient } from '@supabase/supabase-js'; // ... const SUPABASE_SERVICE_ROLE_SCRET = process.env.SUPABASE_SERVICE_ROLE_SCRET; const client = createClient(SUPABASE_URL, SUPABASE_SERVICE_ROLE_SCRET, { // ...opzioni }); ``` ## Sommario In questo articolo, esploriamo l'integrazione di Logto con Supabase, mettendo in luce informazioni chiave e aspetti critici dell'integrazione. Esploriamo concetti come l'autenticazione JWT e le politiche di Sicurezza a Livello di Riga, guidandoti attraverso il processo di integrazione di Logto nella tua applicazione potenziata da Supabase. Con questa conoscenza, speriamo che tu possa migliorare con fiducia la sicurezza, la funzionalità della tua applicazione e persino estendere i tuoi progetti con funzionalità aggiuntive.