Errore Supabase: "Unsupported provider: provider is not enabled"

Aggiungi un pulsante "Accedi con Google" alla tua app e lo premi. Invece della scelta dell'account di Google, il browser mostra questo:

{"code":400,"error_code":"validation_failed","msg":"Unsupported provider: provider is not enabled"}

La barra degli indirizzi mostra il tuo progetto Supabase, qualcosa come https://abcdefghij.supabase.co/auth/v1/authorize?provider=google&redirect_to=…. Hai costruito l'app con Lovable, Bolt, v0, Cursor, Claude Code o Replit, il pulsante è arrivato con il codice, e in quel codice niente sembra sbagliato.

"Unsupported provider: provider is not enabled" significa che Supabase Auth, la parte di Supabase che fa accedere le persone, ha Google disattivato nel progetto con cui parla la tua app. La soluzione è un interruttore e due valori che ti dà Google. Dopo, Google controlla una lista sua, ed è da quella lista che arriva l'errore successivo, redirect_uri_mismatch.

La trappola è in quella seconda lista. L'indirizzo che sembra giusto per lei è quello della tua app, e Google non lo usa mai, perché Google non manda mai nessuno alla tua app.

Cosa significa "Unsupported provider: provider is not enabled"?

Significa che Supabase si è rifiutato di avviare un accesso con Google, perché Google è disattivato nel progetto che ha ricevuto la richiesta.

Accedere con Google è un viaggio di andata e ritorno attraverso due reception. La tua app manda la persona alla reception di Supabase. Supabase la manda alla reception di Google per dimostrare chi è, Google la rimanda a Supabase, e Supabase la riporta a casa, nella tua app, con l'accesso fatto. Ogni reception manda le persone solo dove le sue impostazioni lo permettono. Questo messaggio è la reception di Supabase che dice che lo sportello di Google è chiuso.

Nel codice sorgente di Supabase Auth, una richiesta a /auth/v1/authorize cerca prima il provider, e qualsiasi problema con lui torna come un 400, con il codice validation_failed e Unsupported provider: davanti al motivo. provider is not enabled è la prima cosa che quella ricerca controlla.

Quindi Google non ha mai visto la richiesta, e niente nella console di Google la spiegherà. Neanche la tua app vede l'errore: la libreria JavaScript di Supabase manda l'intero browser a quell'indirizzo, quindi la pagina che fallisce è di Supabase, e la console della tua app resta vuota.

Lo stesso messaggio compare con GitHub, Apple o qualsiasi altro provider disattivato, e l'interruttore è nello stesso posto. Le app sul backend integrato di Lovable sono configurate in un altro modo: la documentazione sull'autenticazione di Lovable descrive Google come "managed by Lovable with no setup, or your own Google Cloud OAuth credentials." Questo articolo è per le app sul tuo progetto Supabase, qualunque sia lo strumento con cui le hai costruite.

È il progetto Supabase giusto?

Controllalo prima di cambiare qualsiasi cosa, perché la pagina di errore nomina il progetto che ha risposto.

L'indirizzo della pagina di errore comincia con il riferimento del tuo progetto, la sequenza di lettere prima di .supabase.co. Apri la dashboard di Supabase e guarda la sua barra degli indirizzi: lo stesso riferimento segue /project/. Se i due sono diversi, la tua app parla con un altro progetto, per esempio uno che un builder ha creato per te o una copia che hai fatto per le prove. È in quel progetto che Google va attivato.

Come risolvere "Unsupported provider: provider is not enabled"

Crea un client OAuth su Google, poi attiva Google in Supabase con i due valori che ti dà. La guida all'accesso con Google di Supabase ha i passaggi; eccoli nell'ordine in cui li chiedono le due console. Le etichette sono quelle delle due interfacce in inglese.

In Supabase, copia prima l'URL di callback. Vai su Authentication, poi su Sign In / Providers, e apri Google. Il pannello mostra una Callback URL con un pulsante per copiarla. Ha questa forma: https://<project-ref>.supabase.co/auth/v1/callback.

In Google Cloud, crea il client. Nella pagina Clients di Google Auth Platform, crea un ID client OAuth di tipo Web application.

• In Authorized JavaScript origins, aggiungi l'indirizzo della tua app, per esempio https://yourapp.com.
• In Authorized redirect URIs, incolla l'URL di callback che hai copiato da Supabase.
• Premi Create e copia subito il Client ID e il Client Secret. La pagina di aiuto di Google sui client OAuth avverte: "you will only be able to view and download the full client secret once, at the time of its creation."

Di nuovo in Supabase, attivalo. Attiva Enable Sign in with Google, incolla il Client ID in Client IDs e il secret in Client Secret (for OAuth), e salva. La dashboard non salva Google attivo senza un Client ID, ma lo salva con il campo del secret vuoto. La descrizione di quel campo dice che il secret serve per "the OAuth flow on the web", e un pulsante in un'app web è proprio quel flusso.

Poi premi di nuovo il tuo pulsante. Se il messaggio comincia ancora con "Unsupported provider", la sua fine ti dice cosa manca:

Perché poi Google risponde redirect_uri_mismatch

Perché il tuo URL di callback non è nella lista del client, scritto esattamente come lo manda Supabase.

Questa è la seconda reception. Quando Supabase avvia l'accesso, passa la persona a Google con un biglietto che dice dove rimandarla: l'URL di callback del tuo progetto. Google confronta quel biglietto con le Authorized redirect URIs del client che hai creato. La sua documentazione OAuth descrive l'errore in una riga: "The redirect_uri passed in the authorization request does not match an authorized redirect URI for the OAuth client ID."

La corrispondenza è esatta. La stessa pagina dice: "the http or https scheme, case, and trailing slash ('/') must all match." Quindi una voce che finisce con /auth/v1/callback/, con una barra in fondo, non corrisponde all'indirizzo che manda Supabase.

L'indirizzo della tua app non fa niente in questa lista. Google rimanda le persone a Supabase, quindi l'unico indirizzo che controlla è il callback di Supabase. L'indirizzo della tua app va nella lista dell'altra reception, Redirect URLs in Supabase, che decide dove Supabase manda le persone alla fine di tutto. Quando quella lista è sbagliata, le persone tornano con l'accesso fatto su localhost:3000, e per questo c'è un articolo apposta.

Dopo aver salvato, dai a Google un po' di tempo. La sua pagina di aiuto sui client OAuth dice: "It may take 5 minutes to a few hours for changes made to these settings to take effect."

Dove va il Client Secret

Nella dashboard di Supabase, e da nessun'altra parte. Il codice della tua app non ne ha mai bisogno.

Il Client ID è pubblico: viaggia nell'indirizzo della pagina di accesso di Google, dove chiunque può leggerlo. Il Client Secret è ciò che dimostra a Google che una richiesta arriva dalla tua parte, e in questa configurazione ce l'ha solo Supabase. Quando la tua app chiama signInWithOAuth, la libreria manda il browser a Supabase, ed è Supabase Auth a parlare con Google usando il secret.

Quindi, se il tuo builder ha messo il secret nel codice della tua app, o in una variabile il cui nome comincia con VITE_ o NEXT_PUBLIC_, è nel browser di ogni visitatore. Quelle variabili sono pubbliche per progetto. La pagina di aiuto di Google è chiara: "Never add client secrets directly in your code or check them into version control systems such as Git or Subversion." Sostituiscilo nella pagina del client nella console di Google: premi Add Secret, incolla il nuovo secret in Supabase, poi Disable su quello vecchio ed eliminalo. Togli anche il vecchio valore dal tuo codice.

Per controllare cosa consegna ai visitatori la tua app online non serve aprire il builder. La nostra scansione gratuita legge la tua app online come fa il browser di un visitatore e segnala le chiavi segrete che riconosce, insieme alle tabelle che rispondono a chiunque e agli header mancanti. Dura circa 20 secondi e non chiede un account: scansiona la tua app.

Tenere d'occhio l'app in cui ora le persone accedono

Appena le persone accedono con Google, i loro account vivono nel tuo progetto Supabase, e l'app in cui accedono cambia a ogni deploy.

Reeve Monitor continua a controllare la tua app online:

• se risponde, ogni 60 secondi
• tutti e nove i controlli ogni ora, su un massimo di tre app, comprese le chiavi segrete nel codice che la tua app invia ai visitatori
• un messaggio quando un risultato cambia, così una chiave uscita con un deploy successivo ti raggiunge senza che tu debba andare a guardare
• un report mensile, in linguaggio semplice, di quello che ha visto

Reeve Care tiene una copia del tuo database Supabase, account compresi:

• una copia cifrata secondo una pianificazione, sullo spazio di archiviazione di Reeve nell'UE, fuori dal tuo account Supabase
• lo schema auth, dove Supabase tiene ogni utente e l'identità Google con cui ha fatto l'accesso, così tornano insieme a tutto il resto
• ogni copia verificata prima che conti, contando le righe di ogni tabella
• anche i tuoi file caricati, appena colleghi una credenziale di Storage
• un ripristino in un clic, con una copia di sicurezza dello stato attuale presa prima
• tutto quello che fa Monitor

Cosa fare adesso

Se le persone superano Google e poi finiscono sulla pagina sbagliata, l'articolo sui reindirizzamenti riparte da lì. La checklist di sicurezza in 10 minuti copre cos'altro guardare prima del lancio.