Project

General

Profile

Actions

Bug #10905

closed

Des tables sur lesquelles un utilisateur de BD n'a aucun droit d'accès s'affichent dans la liste

Added by David Lesimple about 2 years ago. Updated about 2 years ago.

Status:
Closed
Priority:
Urgent
Start date:
08/30/2019
Due date:
% Done:

100%

Estimated time:
Navigateur:
Tous
Votre version de Silverpeas:
6.1-x
Système d'exploitation:
Votre base de données:
Toutes
Livraison en TEST:
Livraison en PROD:

Description

Cf https://tracker.silverpeas.org/issues/10776?issue_count=489&issue_position=55&next_issue_id=10775&prev_issue_id=10777#note-25

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.

Actions #2

Updated by Nicolas Eysseric about 2 years ago

  • Status changed from New to Assigned
Actions #3

Updated by David Lesimple about 2 years ago

  • Subject changed from Des tables sur lesquelles un utilisateur de BD s'affichent dans la liste to Des tables sur lesquelles un utilisateur de BD n'a aucun droit d'accès s'affichent dans la liste
Actions #4

Updated by Miguel Moquillon about 2 years ago

  • Status changed from Assigned to Feedback
  • Target version set to 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 ?

Actions #5

Updated by Nicolas Eysseric about 2 years ago

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...

Actions #6

Updated by Miguel Moquillon about 2 years ago

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 ?

Actions #7

Updated by David Lesimple about 2 years ago

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.

Actions #8

Updated by Miguel Moquillon about 2 years ago

  • Status changed from Feedback to 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.

Actions #9

Updated by Miguel Moquillon about 2 years ago

  • Status changed from In progress... to Resolved
Actions #10

Updated by Nicolas Eysseric about 2 years ago

  • Status changed from Resolved to Integration in progress...
Actions #11

Updated by Nicolas Eysseric about 2 years ago

  • Status changed from Integration in progress... to Closed
  • % Done changed from 0 to 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).

Actions #12

Updated by Marc Avenel about 2 years ago

  • Status changed from Closed to Re-opened
  • Priority changed from Normal to Urgent

Impossible d'ajouter un enregistrement (Idem ticket 10993: https://tracker.silverpeas.org/issues/10993)

Actions #13

Updated by David Lesimple about 2 years ago

  • Status changed from Re-opened to 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

Actions

Also available in: Atom PDF