Forum Programmation.SQL Une table group pour gérer les droits utilisateurs ?

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes : aucune
0
18
mar.
2015

Bonjour, je suis en train de me dire qu'il serait que je met en place une table "group" dans ma base de données afin de bien gérer les droits des différents types de membres. Mais je ne sais pas quel structure choisir. J'hésite entre créer directement un champ pour chacun des droits, par exemple :

close_forum_thread
remove_forum_thread

edit_forum_post
remove_forum_post

edit_user_profile

edit_user
remove_user

add_article
edit_article
remove_article

etc.

La liste peut être longue, donc je me demande s'il ne serait pas plus judicieux de créer plutôt une seconde table contenant des enregistrement pour chaque droit.

Merci pour vos conseils :)

  • # Si c'est mieux

    Posté par  (site web personnel, Mastodon) . Évalué à 2.

    Àma c'est mieux de créer une seconde table "droit" qui contient la liste

    close_forum_thread
    remove_forum_thread
    edit_forum_post
    …

    du coup c'est du 1/n avec la table membre donc table de jointure entre les deux.
    Ça évite d'avoir une table de 40000 champs dont 39990 vide.

    mes 2 cents

    • [^] # Re: Si c'est mieux

      Posté par  . É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 <-+
        |--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…)

  • # Commentaire supprimé

    Posté par  . Évalué à 2.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Ca dépend...

      Posté par  (site web personnel) . Évalué à 1.

      Pour le moment j'ai juste besoin de quelque chose de basique. Au départ, j'utilisais juste un champ role dans la table user pour définir les droits des utilisateurs, mais ça a ses limites. Actuellement j'ai une table user_groups avec plusieurs champs qui me permettent de terminer les droits.

      J'ai quatre groupes : administrator, super_moderator, moderator et member. Donc si un groupe possède la valeur edit_post à true, l'utilisateur pourra modifier un message sur le forum etc.

      Au niveau des droits, je ne pense pas faire quelque chose de complexe, car c'est un site communautaire ou chaque membre possède un profil, des albums photos, etc. J'ai juste besoin de séparer certaines actions entre les différents types de modérateurs et les membres.

  • # Finallement...

    Posté par  (site web personnel) . Évalué à 1.

    Je m'étais pas aperçu que le framework que j'utilise propose tout un système de droits pour chaque objet, donc autant l'utiliser :)

    • [^] # Re: Finallement...

      Posté par  . Évalué à 2.

      oui, parfois c'est plus facile que de reinventer la roue,
      mais c'est moins ludique ;)

      • [^] # Re: Finallement...

        Posté par  (site web personnel) . Évalué à 1.

        Oui c'est clair, d'autant plus que le système proposer permet pas mal de souplesse dans l'affectation des droits. Bon par contre, c'est très complexe à utiliser et un peu lourd à mon goût, mais je suppose qu'il n'y a pas de meilleures solutions que les fameux ACLs. Au départ j'étais parti pour mélanger l'authentification et les acls afin de définir les droits pour chaque action, mais ça devient vite le bordel alors que j'en ai pas spécialement besoin. Je suis donc parti sur un auth classique couplé aux ACLs. :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.