Bug #10905
fermé
Des tables sur lesquelles un utilisateur de BD n'a aucun droit d'accès s'affichent dans la liste
100%
Description
Contexte: Un utilisateur "A" de base de données (au sens technique, donc déclaré au niveau du SGBD) n'a accès qu'à certaines tables.
Si il se connecte à une application myDB utilisant une datasource configuré avec un utilisateur "B" ayant accès à toutes les tables, alors l'utilisateur "A" voit
ces tables dans la liste des tables de l'application myDB.
Si il sélectionn une table sur laquelle il n'a pas de droits d'accès, un message d'erreur survient à juste titre.
Au final, il faudrait que n'apparaisse dans la liste que les tables auxquelles l'utilisateur "A" a réellement accès.
Mis à jour par David Lesimple il y a plus de 4 ans
- Sujet changé de Des tables sur lesquelles un utilisateur de BD s'affichent dans la liste à Des tables sur lesquelles un utilisateur de BD n'a aucun droit d'accès s'affichent dans la liste
Mis à jour par Miguel Moquillon il y a plus de 4 ans
- Statut changé de Assigned à Feedback
- Version cible mis à Version 6.1
Si je comprend bien, il faudrait que chaque utilisateur qui accède à MyDB puisse, avant tout usage et quel que soit son rôle dans l'application, définir lui-même les accès à la base de donnée dans l'onglet "Paramètres de Connexion" et persister en base de données ce lien entre l'utilisateur Silverpeas et celui base de donnée.
Si c'est le cas, ceci signifierai que le gestionnaire définit lui, de son côté, la base de donnée à accéder par l'application MyDB. Une fois ceci fait, les publieurs et les lecteurs ne pourront pas modifier cette liaison applicative (les champs dans "Source de données" et "Descriptions" sont pour eux en lecture seule). Évidemment, seul les gestionnaires et publieurs pourront modifier ou insérer des données dans les tables. Le lecteur ne pourra que consulter.
C'est ça ?
Mis à jour par Nicolas Eysseric il y a plus de 4 ans
Il me semble que c'est une régression fonctionnelle.
Il y a quelques temps, j'avais fait cette correction qui correspondait aux attentes : https://github.com/Silverpeas/Silverpeas-Components/commit/86a1691aa8b4a772e08f3263fed940ddd9348079
Pas besoin d'aller aussi loin donc...
Mis à jour par Miguel Moquillon il y a plus de 4 ans
Hum ... je crois comprendre si je met vos retours avec ce que David m'a dit la semaine dernière. En fait, la datasource pour MyDB est configurée dans le script CLI avec un login et mot de passe. Et donc c'est le profile de cet utilisateur, définit au niveau de la datasource dans Wildfly, qui est utilisé lorsque l'on demande la liste des tables. Or, justement, il n'y a pas besoin, voir, au regard de ce ticket, il ne faut surtout pas configurer un login et mot de passe dans la définition de la datasource dans Wildfly lorsque cette dernière doit être utilisée par JDBCConnector ou par MyDB. Il faut utiliser l'onglet "Paramètres de Connexion" de l'instance de MyDB pour définir les crédences à utiliser. Et normalement ce devrait être le profile de cet utilisateur qui devrait être pris en compte dans le listage des tables accessibles. Peux tu confirmer ou infirmer ce point David ?
Mis à jour par David Lesimple il y a plus de 4 ans
Miguel Moquillon a écrit :
Hum ... je crois comprendre si je met vos retours avec ce que David m'a dit la semaine dernière. En fait, la datasource pour MyDB est configurée dans le script CLI avec un login et mot de passe. Et donc c'est le profile de cet utilisateur, définit au niveau de la datasource dans Wildfly, qui est utilisé lorsque l'on demande la liste des tables. Or, justement, il n'y a pas besoin, voir, au regard de ce ticket, il ne faut surtout pas configurer un login et mot de passe dans la définition de la datasource dans Wildfly lorsque cette dernière doit être utilisée par JDBCConnector ou par MyDB. Il faut utiliser l'onglet "Paramètres de Connexion" de l'instance de MyDB pour définir les crédences à utiliser. Et normalement ce devrait être le profile de cet utilisateur qui devrait être pris en compte dans le listage des tables accessibles. Peux tu confirmer ou infirmer ce point David ?
Je confirme, je vais donc enlever le login et le mdp du cli pour connecteurJDBC et myDB.
Mis à jour par Miguel Moquillon il y a plus de 4 ans
- Statut changé de Feedback à In progress...
Après vérification avec la base d'Akwel, le problème est toujours là même si les crédences ne sont pas passées dans la définition de la source de données dans le script CLI.
Il semblerait que ce soit un pb de définition de privilèges du côté de la base de données. En effet, le ou les utilisateurs ont le privilège de demander la liste des tables de la base, même celles pour lesquelles ils n'ont pas accès ; il est possible que ce soit un privilège par défaut. Aussi, pour palier à ceci, je vais récupérer la correction de Nicolas et l'intégrer dans la V6.
Mis à jour par Miguel Moquillon il y a plus de 4 ans
- Statut changé de In progress... à Resolved
Mis à jour par Nicolas Eysseric il y a plus de 4 ans
- Statut changé de Resolved à Integration in progress...
Mis à jour par Nicolas Eysseric il y a plus de 4 ans
- Statut changé de Integration in progress... à Closed
- % réalisé changé de 0 à 100
Validé et intégré.
La liste des tables proposées tient maintenant bien compte des droits d'accès à ces tables (pour le compte défini via l'onglet Paramètres de connexion de Silverpeas).
Mis à jour par Marc Avenel il y a plus de 4 ans
- Statut changé de Closed à Re-opened
- Priorité changé de Normal à Urgent
Impossible d'ajouter un enregistrement (Idem ticket 10993: https://tracker.silverpeas.org/issues/10993)
Mis à jour par David Lesimple il y a plus de 4 ans
- Statut changé de Re-opened à Closed
Marc Avenel a écrit :
Impossible d'ajouter un enregistrement (Idem ticket 10993: https://tracker.silverpeas.org/issues/10993)
Merci de ne pas ré-ouvrir un ticket alors que le sujet de celui-ci est bien réglé et que vous avez déjà ré-ouvert le bug d'ajout d'enregistrement dans #10993