Pourquoi les liens e-mail de Supabase redirigent vers localhost:3000

Un nouvel utilisateur s'inscrit sur votre app en ligne, ouvre l'e-mail de confirmation et appuie sur le bouton. Son navigateur ouvre une page qui dit "This site can't be reached" et "localhost refused to connect" (dans un Chrome en anglais), au-dessus d'une adresse qui commence ainsi :

http://localhost:3000/#access_token=…&expires_at=…&expires_in=…&refresh_token=…&sb=&token_type=bearer&type=signup

Si votre app utilise le flux PKCE, elle se termine plutôt par ?code=…. Vous avez construit l'app avec Lovable, Bolt, v0, Cursor, Claude Code ou Replit, elle tournait parfaitement en prévisualisation, et la connexion par mot de passe marche toujours.

Une redirection de Supabase vers localhost signifie que Supabase Auth, la partie de Supabase qui connecte les gens, a fini son travail puis a envoyé la personne vers la Site URL de votre projet, qui indique toujours http://localhost:3000. Cette adresse veut dire "cet ordinateur". Sur l'ordinateur de votre utilisateur, il n'y a rien à cet endroit. La solution tient en deux réglages sur une page de votre tableau de bord Supabase.

Voici ce que les solutions rapides qui circulent en ligne font de travers : le joker qui fait disparaître ce message en une ligne est aussi celui qui permet au lien d'un inconnu d'envoyer vos utilisateurs sur sa page, déjà connectés. Les réglages ci-dessous font marcher les liens et gardent cette porte fermée.

Que signifie une redirection de Supabase vers localhost ?

Cela signifie que Supabase a envoyé la personne vers l'adresse par défaut de votre projet, parce qu'il n'en a pas accepté de meilleure.

Chaque e-mail que Supabase envoie pour vous, confirmation d'inscription, magic link, réinitialisation de mot de passe ou invitation, pointe d'abord vers l'adresse propre de votre projet. Le guide des modèles d'e-mail de Supabase en donne la forme : https://project-ref.supabase.co/auth/v1/verify?token=…&type=email&redirect_to=https://example.com/path. Supabase y vérifie le jeton, puis envoie le navigateur vers ce que nomme redirect_to.

Voyez cela comme un poteau indicateur à la porte de Supabase. Chaque personne qui ouvre un lien est connectée à la porte, puis envoyée plus loin, la clé à la main, le long d'une des flèches. Les flèches, c'est vous qui les posez. La Site URL est la flèche que tout le monde prend quand aucune autre ne convient, et sur un nouveau projet elle pointe vers http://localhost:3000 : l'atelier où l'app a été construite, qui sur la machine de n'importe qui d'autre est une pièce vide.

Le guide des redirections de Supabase dit que la Site URL définit la redirection par défaut quand aucun redirectTo n'est indiqué dans le code, vous demande de la changer de http://localhost:3000 vers votre adresse de production, et qualifie ce réglage de critique pour les confirmations par e-mail et les réinitialisations de mot de passe.

Pourquoi Supabase ignore-t-il l'adresse demandée par mon app ?

Parce que cette adresse n'est pas dans votre liste Redirect URLs, et que Supabase se rabat sur une autre sans vous le dire.

Votre app peut indiquer où les gens doivent arriver. Dans la bibliothèque JavaScript de Supabase, c'est emailRedirectTo pour signUp et signInWithOtp, et redirectTo pour resetPasswordForEmail et signInWithOAuth. Supabase Auth décide ensuite dans une courte fonction, dans cet ordre :

1. L'adresse demandée par votre app, si elle correspond à une entrée de votre liste Redirect URLs ou se trouve sur le même domaine que votre Site URL.
2. L'adresse de la page d'où venait la requête, telle que le navigateur l'a transmise, selon la même règle.
3. Sinon, la Site URL. Supabase ne signale aucune erreur, et la console de votre app n'affiche rien.

Il prend cette décision à l'envoi de l'e-mail, et l'adresse choisie entre dans le lien. Quand quelqu'un ouvre le lien, Supabase vérifie de nouveau cette adresse avec vos réglages tels qu'ils sont à ce moment-là. La propre réponse de dépannage de Supabase résume la règle en une phrase : pour que l'option redirectTo fonctionne, il faut inscrire l'URL exacte dans le réglage Redirect URLs.

Le même réglage décide où "Sign in with Google" renvoie les gens, donc un bouton Google qui atterrit sur localhost a la même cause. Un bouton Google qui s'arrête plus tôt, sur une page qui affiche "Unsupported provider: provider is not enabled", relève plutôt d'un interrupteur dans Supabase et d'une liste chez Google.

Pourquoi vous ne l'avez pas vu avant le lancement

Parce que les deux façons dont vous avez testé n'atteignent jamais la Site URL.

• La connexion par mot de passe se fait à l'intérieur de la page. Pas de lien d'e-mail ni de passage par la porte de Supabase, donc le poteau n'est jamais lu.
• Si vous construisez avec Cursor ou Claude Code et que votre serveur de développement tournait sur le port 3000 quand vous avez testé l'e-mail, le lien a ouvert votre propre copie locale et a eu l'air de marcher.
• Sur le backend intégré de Lovable, vous ne le rencontrerez peut-être jamais. La documentation sur l'authentification de Lovable dit qu'il règle la Site URL sur votre adresse lovable.app publiée quand vous publiez, et qu'il ajoute un domaine personnalisé aux redirect URLs quand vous le connectez. La même page dit que les apps qui utilisent votre propre projet Supabase ne reçoivent aucune mise à jour automatique.

Le compte est-il confirmé même si la page n'a pas chargé ?

Oui, pour une confirmation d'inscription. Supabase confirme d'abord et n'envoie le navigateur plus loin qu'ensuite.

Dans le code qui traite le lien, le compte est confirmé avant que la redirection parte. La page qui ne charge pas arrive une fois le travail fait. Dites donc à la personne qu'elle peut se connecter sur votre site en ligne avec le mot de passe qu'elle a choisi. Recliquer sur le même e-mail n'aidera pas : le lien marche une fois, et le deuxième clic répond "Email link is invalid or has expired".

Un magic link ou une réinitialisation de mot de passe, c'est différent. Cette connexion est partie vers localhost et y est restée, donc une fois vos réglages corrigés, la personne a besoin d'un nouvel e-mail.

Comment corriger la redirection de Supabase vers localhost

Changez la Site URL, puis listez les autres adresses vers lesquelles vous envoyez les gens. Les deux se trouvent sur la page URL Configuration, sous Authentication, dans votre tableau de bord Supabase.

Réglez la Site URL sur votre adresse en ligne, avec https:// devant.https://yourapp.com, écrite en entier. Sans le https://, Supabase la lit comme un chemin sur sa propre adresse, et la personne atterrit sur votre projet Supabase avec "No API key found in request" à la place. Toute adresse de ce domaine est ensuite acceptée à n'importe quel chemin sans entrée dans la liste, donc https://yourapp.com/welcome marche dès que la Site URL est juste.

Ajoutez les autres adresses dans Redirect URLs. La version avec www si les gens l'utilisent, l'adresse publiée chez le builder (https://yourapp.lovable.app, par exemple) si les gens s'y inscrivent, et rien d'autre. Une entrée est un motif, donc https://yourapp.com/** couvre chaque page de ce seul domaine.

Vérifiez ce que demande votre code. S'il transmet window.location.origin, l'adresse est celle sur laquelle la page a été ouverte, et chaque adresse que cela peut produire doit se trouver sur le domaine de votre Site URL ou dans la liste. Comparez-les lettre pour lettre : avec www ou sans, avec https ou sans. Une entrée sans /** à la fin correspond à cette adresse exacte et à rien en dessous.

Vérifiez vos modèles d'e-mail. Un modèle qui construit son propre lien avec {{ .SiteURL }} envoie tout le monde vers la Site URL, quoi que votre app ait demandé. Le guide des redirections de Supabase dit qu'en utilisant l'option redirectTo, vous devrez peut-être remplacer {{ .SiteURL }} par {{ .RedirectTo }} dans vos modèles d'e-mail.

Inscrivez-vous ensuite de nouveau avec une adresse que vous n'avez pas encore utilisée. Un e-mail envoyé avant la correction avec le lien standard de Supabase, et ouvert dans son heure, arrive maintenant sur votre site en ligne, parce que Supabase revérifie l'adresse à l'ouverture du lien. Cela tient tant que http://localhost:3000 ne figure plus dans votre liste.

Quelles Redirect URLs peut-on autoriser sans risque ?

Les adresses exactes qui vous appartiennent. Un joker a sa place pour les déploiements de prévisualisation, et seulement limité à votre propre équipe ou projet.

Le guide des redirections de Supabase le dit nettement : le "globstar" (**) est utile pour le développement local et les adresses de prévisualisation, mais en production il recommande de fixer le chemin de redirection exact de votre Site URL.

La raison, c'est ce qui voyage avec la personne. Dans le flux par défaut, Supabase écrit la nouvelle session dans l'adresse vers laquelle il l'envoie : le code qui la construit ajoute #access_token=…&refresh_token=… à l'adresse de redirection. N'importe quelle page à cette adresse peut lire ces deux valeurs, et avec elles elle est cet utilisateur. Sur le poteau, c'est la flèche qui décide qui reçoit la clé.

Une entrée qui couvre une adresse contrôlée par quelqu'un d'autre est donc une porte d'entrée vers les comptes de vos utilisateurs. N'importe qui peut demander à votre projet d'envoyer par e-mail un lien de connexion à l'un de vos utilisateurs, avec la clé publique qui se trouve dans votre app à dessein, et indiquer sa propre page comme destination. L'e-mail qui arrive vient vraiment de votre app. Le flux PKCE n'y change rien, parce que la personne qui a écrit ce lien a lancé la connexion, et PKCE remet la session à celui qui l'a lancée.

Les motifs qui couvrent des adresses que d'autres peuvent créer :

• ** tout seul couvre toutes les adresses qui existent.
• https://*.vercel.app/** couvre tous les déploiements Vercel d'internet, et n'importe qui peut en créer un. L'exemple de Supabase lui-même porte votre équipe : https://*-<team-or-account-slug>.vercel.app/**.
• https://*.lovable.app/**, https://*.netlify.app/** et la même forme sur le domaine de n'importe quel builder font la même chose pour ce builder. L'exemple de Supabase pour Netlify est limité lui aussi : https://**--my_org.netlify.app/**.

Si vous venez de régler cela en collant un joker, revoyez la liste dès aujourd'hui.

Le lancement est aussi le moment où l'on regarde les autres réglages qui ne comptent qu'en production. Notre scan gratuit lit votre app en ligne depuis l'extérieur et signale ce qu'un inconnu peut atteindre : des tables qui répondent à n'importe qui, des clés secrètes dans le code que votre app envoie, des en-têtes manquants, le certificat. Il prend environ 20 secondes et ne demande aucun compte : scannez votre app.

Garder un œil sur l'app en ligne après le lancement

Ce réglage se corrige une fois. Ce que votre app envoie aux visiteurs change à chaque déploiement, et cette partie peut se surveiller depuis l'extérieur.

Reeve Monitor continue de vérifier votre app en ligne :

• si elle répond, toutes les 60 secondes, pour distinguer "le lien ne marche pas" de "le site est en panne"
• les neuf vérifications toutes les heures, sur jusqu'à trois apps, y compris les clés secrètes dans le code que votre app envoie aux visiteurs
• un message quand un résultat change, pour qu'un problème parti avec un déploiement ultérieur vous parvienne sans que vous alliez voir
• un rapport mensuel, en langage clair, de ce qu'il a vu

Reeve Care garde une copie de votre base de données Supabase, comptes compris :

• une copie chiffrée selon un calendrier, sur le stockage propre de Reeve dans l'UE, en dehors de votre compte Supabase
• le schéma auth où vivent les comptes de vos utilisateurs, pour qu'ils reviennent avec tout le reste
• chaque copie vérifiée avant de compter, en comptant les lignes de chaque table
• vos fichiers envoyés aussi, dès que vous connectez un accès Storage
• une restauration en un clic, avec une copie de sécurité de l'état actuel prise d'abord
• tout ce que fait Monitor

Que faire maintenant

Si les gens cliquent sur le nouveau lien et s'entendent dire qu'il a expiré, ce message a sa propre page. La checklist de sécurité en 10 minutes couvre ce qui reste souvent ouvert dans une app qui vient d'être lancée.