Système de rangs unifié

Bonjour,
Je travaille actuellement sur un projet de CMS modulaire, et je voudrais unifier les éventuels privilèges de ces modules dans un seul système de privilèges.

Je m'étais demandé si pour ce faire, je pouvais par exemple faire trois chaines : une qui contient les noms des privilèges pour que les humain comprennent, une autre pour identifier ces privilèges auprès du système, et enfin une finale pour chaque rang, et qui définit donc quels privilèges sont accordés. En pratique, ça donne ça :

Créer un article:Modifier un article:Supprimer un article
AddArticle:ModArticle:DelArticle
0:1:1

Mais cette méthode est-elle la meilleure ?

Merci pour vos réponses !

salut,
pas trop compris ce que tu voulais faire mais effectivment dans les gestion de droit, on a toujours, le nom de la fonctionnalité pour le système, sa description pour l'utilisateur et ensuite une ou plusieurs valeurs indiquant si on ou pas le droit.

Apres ça peut différer si par exemple dans tes droits tu gère des utlisateurs et des groupes.

Ensuite, quand a la manière de faire, ca va dépendre de la structure de ta base de données, de ton architecture de code ....

Je voulais savoir, en fait, si il n'existait pas de meilleure solution que de "bidouiller" avec les chaines, que l'on tranforme en tableau, etc.
Je ne pense pas faire des droits pour les utilisateurs et les groupes, ce serait trop lourd pour moi !

ben au lieu de bidouiller comme tu dis, pourquoi tu utilises pas une base de données ?

Mais j'utilise une base données !

Je stocke les chaines dans la base de données MySQL...

mwé ben moi j'aurais fait une table utilisateur avec login pass ...
une table fonctionnalités avec le nom court pour l'appli et la description pour l'utilisateur
et une table droitutilisateur avec idutilisateur, idfonctionnalité et droit qui vaut 0 ou 1

OK, je vais bosser dessus, merci de ton aide !

Donc, en résumé :

1. Une table utilisateur.
2. Une table fonctionnalites.
3. Une table privileges avec les correspondances, c'est bien ça ?

Mais ta réponse suscite plusieurs sous-questions de ma part ;) :
Comment faire pour qu'il n'y ai qu'une seule table fonctionnalites puisse marcher pour tous les modules éventuels ?

Merci de ta réponse ! :)

un bout de ma table fonctionnalité :

Citation:

---

idFonc int autoincrement
nomFonc varchar du type "nomModule_nomFonc"
descFonc varchar ça c'est la description
idModule int clé etrangère de la table modules
.....

---

ça permet d'avoir deux fonctionnalité avec le même nom dans des modules différents.

Bon moi j'ai rajouté le nom du module a cause d'une contrainte de code mais t'es pas obligé

Mais alors, si tu as deux modules ayant chacun, disons 150 privilèges, tu as donc 300 entrées dans la table ! Ca ne risque pas de ralentir MySQL (aussi rapide qu'il soit) ?

dans la table de gestion des droits, tu as 3 entiers seulement :
id utilisateur
id fonctionnalité
droit

et tu n'as pas besoin de plus que du tinyint en général.
Donc niveau perfs ça va, et puis 150 entrées dans une table c'est quand même pas énormes.

De plus, je charge un objet utilisateur en session au moment ou il se connecte a l'appli.
Apres, pour consulter ses droits, c est en gros une consultation de tableau.

Il est vrai que si ses droits sont changés pendant sa session ça le prendra pas en compte mais bon ...

D'accord, et toi tu fais de la gestion des droits par groupe ou pas ?

oui aussi mais la selon comment tu veux gérer tes droits ça devient plus complexe

J'envisageais une table avec des colonnes représentant les droits pour chaque fonctionnalité et un char(1).

Je ne l'ai pas encore testé en live, mais qu'en pensez vous ?

euh j'ai pas trop compris là, pour la gestion des droits de quoi ?
des groupes ?

il vaut mieux mettre un tinyint 1 plutot qu'un char 1, c 'est ce dont on se sert en général pour les booleens

Je refléchissais à une gestion de droit par utilisateur et par groupe :

une table contenant les permission :
un champ id, un champ description(purement descriptif), les champs permissions

une table utilisateurs :
avec une id par utilisateurs

une table faisant le lien entre les liens id utilisateurs et permessions.

Est ce clair ? Qu'en pensez vous ?

en fait mes groupes sont considérés comme des utilisateurs donc j'ai la meme structure qu'énoncée précedemment ;)

Oui je vois aussi les choses comme ça ;)

Je voulais avoir un ptit feedback

OK, je voulais donc te remercier, je vais bosser la-dessus maintenant. Si ça marche, je te paye un coup à boire dans le bar de ton choix ! :chin: