Discussion :

[Jon Shannow]

Bonjour à toutes et tous,

Je me pose une question existentielle sur les rôles que je doit créer dans ma base de données.

Voilà, je développe un ERP pour ma société. Cet ERP sera utilisé par mes collègues (et encore pas tous).

Tous ces utilisateurs devront avoir les droits SELECT, INSERT, UPDATE et DELETE sur les tables et les séquences. Seuls les admin auront des droits supérieurs.

Ma question est : dois-je créer un rôle par utilisateur, et ainsi chacun se connecte avec son rôle, ou bien un seul rôle "utilisateur" et tous se connectent avec ce rôle ?

D'abord, est-ce que la seconde solution est possible ? C'est à dire, est-ce qu'il est autorisé d'avoir plusieurs personnes connectées en même temps avec le même rôle ? Si ça n'est pas possible, ça simplifie le questionnement. Il faut un rôle par utilisateur susceptible de se connecté.

Ensuite, si les deux solutions sont possibles laquelle est à privilégier ? Et quels sont les avantages et les inconvénients de ces deux méthodes ?

Merci d'avance pour vos réponses avisées et éclairantes.

JS

[tatayo]

De ce que je vois dans l'aide en ligne, un rôle peut être affecté à plusieurs utilisateurs.
Donc "de moins point de vue", je créerai (au moins) un rôle, j'affecterai les utilisateurs à ce rôle et je gèrerai les droits au niveau du rôle.

Ainsi la gestion des droits sera "centralisée", vu qu'un utilisateur héritera des droits du rôle auquel il est affecté.

Tu peux par exemple avoir un rôle "comptabilité" qui ne peut pas créer de fiche article, un rôle "référencement" qui lui ne peut pas créer de fiche client...

Tatayo.

[Jon Shannow]

Merci de ta réponse. C'est encore une autre solution à laquelle je n'avais pas pensé. Avoir des droits par "secteurs" d'activité.

JS

[escartefigue]

Bonjour,

Il ne faut pas confondre les droits gérés par la BDD et ceux gérés par l'application.

Dans un ERP, on définira des profils métier : gestionnaire de commande client, comptable, responsable logistique, etc.

Chacun de ces profils métier sera associé à des fonctions : consulter les commandes clients, créer des commandes client, visualiser des comptes clients, créer des comptes clients, consulter les stocks... Certaines fonctions étant communes à plusieurs profils métiers.

Au niveau BDD, il faut attribuer des droits suffisants pour que les fonctions requises puissent être exercées par les profils et donc les personnes rattachées.

[Jon Shannow]

Merci de cette remarque tout à fait juste.

Dans l'appli, j'ai une gestion de rôles, des droits associés aux rôles, et des associés aux utilisateurs.

Pour la partie BDD, je me demandais s'il fallait créer un "rôle" Postgresql pour chaque utilisateur ou pas.

[escartefigue]

Sur ce dernier point, je rejoins évidemment la position de Tatayo, pas de gestion individuelle, ce serait une charge énorme et inutile.

[Jon Shannow]

Oui, mais je me heurte à un truc.

Dans un trigger sur le serveur Postgre, je voudrais indiquer quel est le dernier utilisateur à avoir modifié ou ajouté un supprimé un enregistrement sur certaines tables.

Mais, si plusieurs utilisateurs partagent le même "rôle" postgre comment connaitre le "vrai" utilisateur qui a fait l'opération ?

[SQLpro]

C'est la limite d'un système comme PostgreSQL qui n'est pas intégré à l'OS.... Dans d'autres SGBDR, par exemple Microsoft SQL Server, vous avez toujours accès par un moyen ou pas un autre à l'utilisateur au niveau système, voire l'adresse IP du client par requête :

• SYSTEM_USER : fonction de la norme SQL pour obtenir le nom de connexion au serveur
• toutes autres informations via la vue système sys.dm_exec_connections

PostGreSQL fournit une liste limitée des info dans pg_stat_activity

A +