Règles d'accès dans l'export
Un export Postgres inclut des politiques de sécurité au niveau des lignes qui reproduisent les lignes que chacun de vos utilisateurs peut lire. Vous les appliquez vous-même, et elles ne couvrent que la lecture.
Ce que les politiques reproduisent
Le bundle d'export inclut policies.sql, qui met en place la sécurité au niveau des lignes sur les tables exportées. Un utilisateur voit une ligne quand il en est propriétaire, quand elle est publique, quand elle lui a été explicitement accordée, ou quand elle dépend de quelque chose qu'il peut déjà voir. Ce dernier cas porte sur un niveau, via une référence qui transmet l'accès en lecture. Les octrois explicites circulent dans leur propre table, que les politiques consultent et que les utilisateurs ne peuvent pas lire directement.
Dans Fóir, les règles sont appliquées dans la base de données, compilées par Demesne sur une seule table d'enregistrements. L'export a une table par modèle : les mêmes règles sont donc réécrites pour cette forme.
Les appliquer
Vous exécutez le fichier avec psql après le chargement des données. Appliquer le bundle via la commande d'export ne l'exécute pas. À partir de là, le contrat est un unique paramètre de session, request.jwt.claims, qui porte l'id de l'utilisateur. Sans claims définis, l'appelant est anonyme et voit exactement les lignes publiques. Testez avec le rôle authenticated : le rôle qui a restauré les tables en est propriétaire, et le propriétaire d'une table contourne la sécurité au niveau des lignes.
Ce qui ne se transfère pas
Les permissions au niveau du champ, les portées d'API et les règles d'écriture restent derrière. Un utilisateur qui peut voir une ligne dans la base restaurée en voit toutes les colonnes : masquer un champ devient donc le travail de votre application, d'un octroi sur colonne ou d'une vue. Les politiques donnent aux appelants anonymes et connectés un accès en lecture seule, et l'accès à la console de votre équipe n'est pas exporté.
Ce qui est testé
Notre suite de tests exporte un projet de test, le restaure dans une seconde base, applique les politiques et exige les mêmes id de lignes pour le même utilisateur des deux côtés. Cela teste la traduction, et rien ne vérifie les politiques sur votre propre base restaurée. Nous ne prétendons pas que les règles restaurées correspondent pour un projet qui utilise des organisations.
Lire le détail
La section sur les règles d'accès du guide d'export montre comment appliquer les politiques, définir les claims d'un utilisateur et tester avec le bon rôle.