Vous n'êtes pas identifié(e).
Pages : 1
Salut,
Après avoir lu quelques tonnes de docs, j'en suis venu à la conclusion que mon appli ne devait avoir d'accès en lecture qu'à travers des vues.
Cependant certains aspects restent obscurs: notamment comment faire pour que X voit les champs a,b,c mais que Y ne voit que a,c, le tout sur une même vue (enfin si cela est possible).
Un rapide test m'a démontré que les droits SELECT (CHAMPS) définis user par user sont outrepassés par les droits SELECT accordés sur une même vue (en l'occurence, X avait tous les droits SELECT (CHAMPS) sur a,b & c, Y seulement sur b, mais la vue était sur a & c et Y voyait quand même les champs interdits).
La conclusion "logique" de ce chtit test, c'est qu'il me faudrait une vue par type d'utilisateur, le PB, c'est que dans ce cas, cela va vite virer à l'usine à gaz.
Donc ma question est: y'a-t'il une possibilité de faire ce que je veux avec seulement une seule vue, ou si cela n'est pas possible, comment puis-je générer automatiquement les vues nécessaires?
Jiff
(jsais pas si j'ai réussi à être très clair sur ce coup-là?)
Hors ligne
À mon avis le plus simple est pour ce cas d'utilisation d'aller en 8.4 et d'utiliser les ACL par colonnes. Les vues sont bien pratiques, mais en termes de perfs c'est une arme à double tranchant : les utilisateurs ont souvent tendance à considérer les vues comme des tables, et à s'en servir comme base pour des requêtes complexes, ce qui peut devenir très lourd en terme de requête réelle (après réécriture par le moteur).
Avec juste des vues, à part une vue par type d'utilisateurs, je ne vois pas de solution simple.
Marc.
Hors ligne
flute, j'ai oublié un point important: les vues se justifient-elles toujours, vu que c'est la version 8.4 de PG que j'utilise ? (s/s entendu: est-ce que les droits sur colonnes ne seraient pas nécessaires et suffisants?)
Hors ligne
oops, je n'avais pas vu l'arrivée de la réponse.
Une fois de plus: merci Marc! (et en plus, cela m'arrange drôlement puisque je développe en parallèle le gestionnaire des droits (tables, champs, procédures...) qui va me permettre de faire d'une pierre deux coups)
Hors ligne
Pour infos, un utilisateur X qui n'a pas le droit de lire la table t1 pourra la lire avec la vue v1 si la vue v1 lit la table t1 et que le propriétaire de la vue v1 a le droit de lire la table t1.
J'ai pas l'impression que je m'explique clairement. En fait, PostgreSQL vérifie les droits de lecture des objets visés par une vue par rapport au propriétaire de la vue et non pas par rapport à l'utilisateur qui regarde cette vue.
Guillaume.
Hors ligne
Donc, pour terminer ce que je voulais dire, je ne suis pas étonné que l'utilisateur Y voit des colonnes dans la vue, colonnes qu'il ne peut pas voir dans la table.
Guillaume.
Hors ligne
Oui, c'est l'explication que j'ai fini par trouver.
Par opposition à la vue, ça va m'obliger à tester tous les droits possibles sur une table pour un user, mais finalement ça n'est pas plus mal puisqu'il faut bien occulter les items des menus auxquels il n'a pas droit (sans compter la construction correcte des requêtes en lecture).
De plus, juste avec les droits tables/champs, je devrais normalement éviter ce genre d'effet de bord.
Hors ligne
Pages : 1
