Je vais configurer la sécurité au niveau des lignes de PostgreSQL afin que chaque utilisateur ne voie que ses propres données, Supabase inclus

Toute application avec des comptes d'utilisateurs, des plans payants ou plusieurs équipes dans une seule base de données doit décider qui peut voir quelles lignes. Si cette règle ne réside que dans le code de l'application, elle échoue la première fois que quelqu'un accède aux données d'une autre manière: un nouveau point de terminaison que quelqu'un a oublié de protéger, une deuxième application sur la même base de données, ou l'API que Supabase génère pour vos tables. La sécurité au niveau des lignes place la règle là où se trouvent les données.

J'ai fait cela sur un produit d'abonnement sous NDA: des politiques de sécurité au niveau des lignes sur les tables et un rôle de base de données distinct pour chaque niveau d'abonnement, de sorte que ce qu'un plan inclut est appliqué par PostgreSQL, et non par une vérification que quelqu'un pourrait oublier.

Dans Starter, j'examine les politiques que jusqu'à cinq tables ont ou n'ont pas et j'envoie une liste écrite des lacunes, avec un exemple de requête qui montre chacune d'elles. Standard écrit ou corrige les politiques sur jusqu'à dix tables, configure les rôles dont votre application a besoin, les livre sous forme de fichiers de migration et ajoute des tests dans lesquels l'utilisateur A essaie de lire et de modifier les lignes de l'utilisateur B et échoue. Advanced couvre jusqu'à vingt-cinq tables, ajoute des limites de plan ou de niveau appliquées dans la base de données et exécute les tests en CI.

Sur Supabase, les mêmes fonctionnalités PostgreSQL s'appliquent, avec auth.uid() et les revendications JWT utilisées dans les politiques. Sur PostgreSQL simple, les politiques lisent l'utilisateur actuel à partir d'un paramètre de session que votre backend définit pour chaque requête.

Pas d'appels. Chaque package se termine par une note en langage clair sur qui peut voir quoi; sur Standard et Avancé, les politiques arrivent également sous forme de migrations dans votre dépôt, avec les tests. Pendant 14 jours après la livraison, je corrige gratuitement tout ce qui ne fonctionne pas comme convenu.

Étapes pour la réalisation de votre projet
1. Cartographier les données - Je liste les tables, qui possède chaque ligne, et qui devrait la lire ou la modifier: propriétaires, membres de l'équipe, administrateurs, chaque plan.
2. Examiner ce qui existe - Les politiques, les autorisations et les rôles actuels sont vérifiés par rapport à cette carte, et chaque lacune est notée avec une requête qui la montre.
3. Politiques et rôles - Les politiques sont écrites par table et par action, avec des rôles pour les plans ou les équipes, sous forme de fichiers de migration que vous pouvez examiner.
4. Prouver - Les tests se connectent en tant que différents utilisateurs et essaient de lire et de modifier les données des autres. Chaque action interdite doit échouer, et chaque action autorisée doit fonctionner.
5. Transfert - Une courte note en langage clair sur qui peut voir quoi, les migrations, et comment ajouter une politique lorsqu'une nouvelle table apparaît.