Discussion :

[Tidus159]

Bonjour,

voila j'ai souvent eu ce problème dans mes développements et j'aurais aimé avoir votre avis. (j'ai fait plusieurs recherches mais le mot clef droit est très utilisé)
Dans une application, il est classique d'avoir différents type d'utilisateurs :
- Administrateur
- Utilisateur avec droits particuliers sur l'application...

Dans mon cas, une personne n'a pas nécessairement un compte sur l'application.
Un compte a un seul rôle applicatif.

Donc la modélisation classique est simple :
Personne 0 1 ------------ 1 1 Compte 1 1 ------------- 0 N Role

Avec Compte(id, pseudo, mot_de_passe)
pour rôle je pensais mettre uniquement
Role (id, libellé)

ainsi dans cette table j'aurais :
1 Administrateur
2 Directeur de projet
3 Chef de projet
4 Responsable
5 Utilisateur (cad lambda)

Le problème au niveau applicatif est l'utilisation de cette table :
- faire un test sur les identifiants est une mauvaise idée car un rôle peut être ajouté ou supprimé
- faire un test sur le libellé est une mauvaise idée car celui ci peut changer

Je ne vois donc pas de solution propre pour dire que l'administrateur aura tous les droits, le directeur aura beaucoup de droit, etc.

Ma question est donc la suivante : comment effectuer une gestion propre des droits dans l'application ?

Merci par avance.

[Richard_35]

Bonjour Tidus159,

C'est une question toujours intéressante.

Dans ton MCD, tu poses ta stratégie de droit en terme de rôles, et c'est parfait. Mais, il s'agit de la stratégie "en amont", pour l'instant sans implication sur le dévelopement proprement dit. Le diable étant dans le détail...

Sur cette partie, avant d'attaquer le détail en question, peut-être serait-il intéressant que le "pseudo" de "Compte" soit le login Windows (ou autre) que tu peux récupérer dynamiquement dans (je suppose) tous les langages de tous les OS.

Non ?

[Tidus159]

Bonjour,

Je ne pense pas me servir du login Windows car le site sera un extranet (possibilité d'utiliser le site de chez soi ou de chez un client).
Néanmoins, on peut mettre en place ce conseil qui est de dire que le pseudo de l'utilisateur sera son compte Windows (ce qui est une bonne idée), mais cela restera un choix de l'administrateur du site.

[Richard_35]

OK.

La question de fond que tu soulèves est donc, en substance : "jusqu'où doit aller la variabilisation des données ?" : il est certain qu'à un moment, il faudra bien indiquer "en dur" quelque part, une valeur à prendre en compte dans le développement.

Donc, tu définis sur les entités suivantes :

Personne 0 1 ------------ 1 1 Compte 1 1 ------------- 0 N Role

Juste une première remarque avant de passer à la suite : tu pourrais te passer de la table Compte en ajoutant, dans la table Personne, son pseudo/mot de passe éventuel, ce couple pouvant ne pas être renseigné. Non ?

[Tidus159]

Re,

Le problème est exactement la "variabilisation" des données.

Oui, je pourrais faire cela mais peu de personnes de la table personne auront un compte (l'entité personne est utilisée pour d'autres associations). Compte comporte d'autres données (date_derniere_connexion, date_creation).
Cela me permet d'éviter d'avoir plusieurs colonnes à NULL dans personne ;-).

[Richard_35]

OK.

Donc, nous avons les entités suivantes :

Personnes
- Id_Personne (PK)
- Nom
...

Comptes
- Id_Compte (PK)
- Pseudo
- Mot_de_passe
- Id_Personne
- Id_Role
...

Roles
- Id_Role (PK)
- Libelle
...

Relations
Personnes -(0,1)---[possède le compte]--[est attribué à]---(1,1)-Comptes, via Id_Personne ;
Roles -(0,n)---[a pour compte]--[a pour rôle]---(1,1)-Comptes, via Id_Role.

Tu pourrais prévoir un niveau supérieur de Rôles qui serait :
Types_Roles
- Id_Type_Role (PK)
- Libelle
...
auquel cas, tu aurais :
Roles
- Id_Role (PK)
- Libelle
- Id_Type_Role
...

Nouvelle relation :
Types_Roles -(1,n)---[a pour rôles]--[est de type]---(1,1)-Roles, via Id_Type_Role.

C'est, sans doute, à ce niveau de "variabilisation" qu'il convient de s'arrêter. Mais bon, nous pouvons, dans l'absolu, ajouter autant de niveau que nous voulons.

Enfin, dans l'application, il conviendra de tester à quel type de rôle appartient le compte connecté pour, avant chaque ouverture de fenêtre de saisie, déterminer, par exemple, si cette fenêtre doit s'ouvrir en lecture seule ou non.

Nous voyons donc apparaître d'autres entités :
Fenetres
- Id_Fenetre (PK)
- Libelle
...

Fenetres_TypeRole
- Id_Fenetre (PK)
- Id_Type_Role (PK)
- Modification_autorisee (oui/non)
...

Je te laisse deviner les relations (n,n).

En final, à un moment donné, nous ne pourrons pas éviter la saisie "en dur", donc l'arrêt de la "variabilisation".

[Tidus159]

Excellente idée, je vais utiliser ta solution comme elle est :-).

Merci, "et à bientôt" !

@+,
Tidus.