Par contre, pour l'OP, petites précisions: la gestion des droits est quelque chose d'assez complexe, si tu veux faire quelque chose de fin. Donc, que veux-tu faire exactement?
Par exemple pour autoriser l'insertion d'un post dans une section mais pas dans une autre, tu n'auras pas le choix: les sections seront probablement des entrées d'une table dédiée. Il te faudra donc les associer avec des droits.
Du coup, pour moi, tu auras quelque chose du genre:
entry <-+
|--rights
role <--+
entry: entrée de forum (section, message public, message privé...)
role: utilisateur, groupe. Postgres les appelle tous "rôle", c'est juste que certains peuvent se connecter et d'autres pas :)
Si tu tiens à implémenter manuellement la gestion des groupes et des utilisateurs, en admettant qu'il soit possible pour un utilisateur de faire partie de plusieurs groupes, ou même qu'un groupe puisse faire partie d'un ou plusieurs groupes parents tout en permettant d'attribuer des droits à un utilisateur précis (dernier point qui, à mon avis, n'est pas une bonne idée, parce que sur la longueur ça va être chiant de gérer les exceptions pour l'administrateur), il va te falloir créer trois autres tables telles que:
role <-2----------- role_link
^
|
+------+---------+
| |
user group
Explication:
L'utilisateur est un rôle (il complète les informations de la table role) tout comme le groupe (je ne l'ai mis que au cas où il y ait des infos spécifiques pour les groupes, qu'un utilisateur n'aurait pas). user et group ont donc une clé primaire qui référence la clé primaire de role.
Puis, role_link est ce qui permets d'associer ensemble divers rôles, donc, ça peut être 2 groupes, 1 utilisateur et 1 groupe... voire même, 2 utilisateurs (ça me paraît stupide, mais ça peut permettre de gérer des alias: pourquoi pas?).
Les droits étant affectés à un rôle particulier, tu peux du coup affecter soit des droits à un groupe, soit à un utilisateur, puisque chaque rôle devrait être soit un user soit un group (mais il faut implémenter cette règle via des trigger, si tu veux que ce soit garanti).
Bien sûr, la question c'est de savoir quelles fonctionnalités tu comptes implémenter... si tu ne veux pas d'une gestion aussi fine et que tu te limites à la gestion du CRUD, il aussi possible de simplement la gestion des droits de ton SGBDR. Ce qui serait nettement moins risqué en terme de failles de sécurité, puisque ça te mettrais à l'abri d'oublier de vérifier les droits au préalable. Reste que ton SGBDR doit en être capable.
Si c'est juste un truc pour le fun, ne te prends pas la tête à vouloir faire un truc clean: avances par a-coups: implémentes les fonctionnalités l'une après l'autre, quand tu le veux.
Si c'est un projet que tu veux clean mais de faible envergure, essaie de voir ce que ton SGBDR t'offre en matière de gestion des droits: le moins de code tu feras, le mieux tu te porteras.
Enfin, si tu veux un truc chiadé: commences par lister les fonctionnalités dont tu comptes doter ta v1. À partir de ce moment la tu pourras réfléchir à la meilleure architecture, pas avant.
Dans tous les cas: versionne ton code. Apprendre à utiliser git, mercurial, voire même svn, te permettra de gagner beaucoup de temps. Je le dis, parce que ça m'a pris longtemps avant de m'apercevoir que ces outils existent, et que j'ai perdu nombre de projets de cette façon (clé usb, CD ou disque dur qui lâche, 20000 dossiers dont je ne sais plus lequel est le bon...)
[^] # Re: Si c'est mieux
Posté par freem . En réponse au message Une table group pour gérer les droits utilisateurs ?. Évalué à 2.
Je suis d'accord.
Par contre, pour l'OP, petites précisions: la gestion des droits est quelque chose d'assez complexe, si tu veux faire quelque chose de fin. Donc, que veux-tu faire exactement?
Par exemple pour autoriser l'insertion d'un post dans une section mais pas dans une autre, tu n'auras pas le choix: les sections seront probablement des entrées d'une table dédiée. Il te faudra donc les associer avec des droits.
Du coup, pour moi, tu auras quelque chose du genre:
entry: entrée de forum (section, message public, message privé...)
role: utilisateur, groupe. Postgres les appelle tous "rôle", c'est juste que certains peuvent se connecter et d'autres pas :)
Si tu tiens à implémenter manuellement la gestion des groupes et des utilisateurs, en admettant qu'il soit possible pour un utilisateur de faire partie de plusieurs groupes, ou même qu'un groupe puisse faire partie d'un ou plusieurs groupes parents tout en permettant d'attribuer des droits à un utilisateur précis (dernier point qui, à mon avis, n'est pas une bonne idée, parce que sur la longueur ça va être chiant de gérer les exceptions pour l'administrateur), il va te falloir créer trois autres tables telles que:
Explication:
L'utilisateur est un rôle (il complète les informations de la table role) tout comme le groupe (je ne l'ai mis que au cas où il y ait des infos spécifiques pour les groupes, qu'un utilisateur n'aurait pas). user et group ont donc une clé primaire qui référence la clé primaire de role.
Puis, role_link est ce qui permets d'associer ensemble divers rôles, donc, ça peut être 2 groupes, 1 utilisateur et 1 groupe... voire même, 2 utilisateurs (ça me paraît stupide, mais ça peut permettre de gérer des alias: pourquoi pas?).
Les droits étant affectés à un rôle particulier, tu peux du coup affecter soit des droits à un groupe, soit à un utilisateur, puisque chaque rôle devrait être soit un user soit un group (mais il faut implémenter cette règle via des trigger, si tu veux que ce soit garanti).
Bien sûr, la question c'est de savoir quelles fonctionnalités tu comptes implémenter... si tu ne veux pas d'une gestion aussi fine et que tu te limites à la gestion du CRUD, il aussi possible de simplement la gestion des droits de ton SGBDR. Ce qui serait nettement moins risqué en terme de failles de sécurité, puisque ça te mettrais à l'abri d'oublier de vérifier les droits au préalable. Reste que ton SGBDR doit en être capable.
Si c'est juste un truc pour le fun, ne te prends pas la tête à vouloir faire un truc clean: avances par a-coups: implémentes les fonctionnalités l'une après l'autre, quand tu le veux.
Si c'est un projet que tu veux clean mais de faible envergure, essaie de voir ce que ton SGBDR t'offre en matière de gestion des droits: le moins de code tu feras, le mieux tu te porteras.
Enfin, si tu veux un truc chiadé: commences par lister les fonctionnalités dont tu comptes doter ta v1. À partir de ce moment la tu pourras réfléchir à la meilleure architecture, pas avant.
Dans tous les cas: versionne ton code. Apprendre à utiliser git, mercurial, voire même svn, te permettra de gagner beaucoup de temps. Je le dis, parce que ça m'a pris longtemps avant de m'apercevoir que ces outils existent, et que j'ai perdu nombre de projets de cette façon (clé usb, CD ou disque dur qui lâche, 20000 dossiers dont je ne sais plus lequel est le bon...)