« new row violates row-level security policy » : corriger l'erreur Supabase

new row violates row-level security policy for table "projects"

Mon app affiche l'erreur « new row violates row-level security policy for table "projects" » quand un utilisateur connecté enregistre des données.

Ne désactive surtout pas la RLS. À la place :
1. Liste les politiques RLS existantes sur la table concernée.
2. Ajoute une politique INSERT pour le rôle authenticated qui autorise l'insertion seulement si user_id = auth.uid().
3. Si le code fait .insert(...).select() ou renvoie la ligne créée, vérifie qu'une politique SELECT équivalente existe aussi.
4. Vérifie que le front envoie bien user_id avec l'id de l'utilisateur connecté, et que l'enregistrement n'a lieu qu'une fois la session chargée.
5. Si la ligne est créée juste après l'inscription, crée-la plutôt avec un trigger côté base sur auth.users.

Montre-moi le SQL avant de l'appliquer, puis explique-moi en une phrase ce que chaque politique autorise.

Vérifier que c'est réglé

Trois contrôles, dans cet ordre :

1. Refais l'action qui plantait, connecté avec un compte de test. L'erreur ne doit plus apparaître et la ligne doit être créée.
2. Ouvre Supabase, puis Authentication > Policies. Sur ta table, tu dois voir une politique INSERT (et une SELECT si ton app relit ce qu'elle vient de créer).
3. Teste avec un deuxième compte. Il ne doit pas voir les données du premier. Si c'est le cas, la règle est trop large : redemande à Lovable de la limiter à auth.uid().

Les trois causes les plus fréquentes

1. Il n'existe aucune règle d'insertion

C'est le cas classique. Lovable a créé la table et activé la RLS, ce qui est bien, mais n'a écrit que la règle de lecture. Résultat : ton utilisateur peut voir ses données, pas en ajouter.

2. L'utilisateur n'est pas (encore) connecté

La règle compare user_id à auth.uid(), c'est-à-dire l'identifiant de la personne connectée. Si l'enregistrement part avant que la session soit chargée, ou juste après une inscription qui attend la confirmation de l'e-mail, auth.uid() est vide. La comparaison échoue, Supabase bloque.

Pour une ligne créée à l'inscription (un profil, par exemple), un trigger est plus fiable. Un trigger, c'est une petite action que la base déclenche toute seule quand un compte est créé.

3. L'insertion marche, mais la relecture est bloquée

Piège peu connu : si ton code demande à Supabase de renvoyer la ligne qu'il vient de créer (.insert(...).select()), il faut aussi une règle de lecture. Sans elle, tu obtiens le même message d'erreur, alors que la règle d'insertion est correcte.

Ce qu'il ne faut pas faire

Lovable ou un tutoriel peut te proposer de désactiver la RLS pour « faire marcher » l'app. Ça marche, en effet : ta table devient lisible et modifiable par n'importe qui possédant la clé publique de ton app, et cette clé est visible dans le navigateur. Refuse.

Même chose pour une règle du type with check (true) : elle autorise tout le monde à écrire n'importe quoi. C'est l'équivalent d'une porte ouverte avec un panneau « fermé ».

Pour aller plus loin : la règle en SQL

Si tu veux vérifier ce que Lovable a écrit, voici à quoi doit ressembler la règle d'insertion. Tu la retrouves dans Supabase, onglet SQL Editor.

create policy "Chacun crée ses propres lignes"
on public.projects
for insert
to authenticated
with check ( (select auth.uid()) = user_id );

Traduction : seul un utilisateur connecté peut ajouter une ligne, et seulement si la colonne user_id contient son propre identifiant.

Éviter que ça revienne

• À chaque nouvelle table, demande à Lovable : « Crée les politiques RLS SELECT, INSERT, UPDATE et DELETE, limitées à l'utilisateur connecté. »
• Teste toujours avec deux comptes différents avant de partager l'app.
• Lance l'outil Security Advisor de Supabase (menu Advisors) : il signale les tables sans RLS ou sans règles.