Bonjour,
 
 
J'aimerais savoir pour ceux qui l'ont deja fait, quelles sont les meilleures méthodes pour gérer les droits sur un site web, à savoir les personnes qui sont autorisés ou non à acceder à une page ou à une partie du contenu d'une page.
 
Pour le moment j'utilise des if ($_SESSION['']) avec les droits des utilisateurs (de 1 à 5) avant les liens/formulaires ou en début de page.
 
J'ai pensé à une table qui liste tous les liens du site en fonction du droit des utilisateurs...
 
 
A vous...

1/ Gère les droits avec un masque (binaire, caractères, ce que tu veux).
Genre : Achats = 1 (001) / Vente = 2 (010) / Manager = 4 (100)
Ainsi, une hôtesse de saisie aux achats à le droit 1, une au ventes à le droit 2. Une personne qui s'occupe des deux à la fois, 3.
Et pour les managers de chacun des trois servives : 5 (101), 6 (110) et 7 (111)
 
2/ Dans toutes les pages, tu fait un include d'une librairie qui contient entre autres "checkAuthorization(needed, granted)" permettant de retourner true ou false selon si le profil en session correspond à la constante décrire. Attention, il faut que l'admin des ventes (110) ait accès à la fois aux pages ne nécessitant que des ventes (010), ou manager (100).
 
3/ Ensuite, en début de chaque page, tu appelles cette fonction pour savoir si la personne peut au moins charger ou non la page, et tu gère le cas échéant (si possible via une fonction dans ton include, histoire d'éviter la redondance de code).
 
4/ Mais tu peux aussi appeler cette fonction pour affiner les possibilités sur une page.
 
Par exemple, une page listant les produits.
Les personnes aux achats et aux ventes, ainsi que les managers doivent pouvoir la voir. Tu mets donc aucun droit (000).
Par contre, seules les hôtesses de saisie des achats ont le droit de modifier certaines infos. Donc selon le droit 001, tu affiches par exemple la description des produits sous forme d'un champ saisissable ou non. Idem pour les prix, de vente et d'achats, que tu n'attribueras qu'aux droits managers des deux services (101 ou 110)
Etc.
 
C'est une solution simple et très efficace.
 
Tu peux affiner par la suite en reproduisant le système des ACL de Windows, en créant des groupes (par contre là tu dois laisser tomber le coup du masque binaire, pour passer à un masque ternaire (attribué/révolqué/hérité du père)

+1  
je l'ai déjà fait. Le mieux c'est pour stocker les droits dans la bdd. Tout dans un int et hop

 
Tout à fait d'accord avec tout le post, sauf cette partie : je comprend pas à quoi ça sert de stocker 3 valeurs ? En plus ça empeche toute opération sur les bits, ce qui est quand même dommage    

parceque si tu veux hériter des droits "groupe" au niveau de tes utilisateurs, il faut conserver un masque libre pour la propagation. sinon, tu dois oublier la possibilité de combiner les deux types de droits, ce qui peut être limitant quand on en a besoin...
 
pour reprendre mon exemple ci-dessus...
 
2 groupes :
achat 001
ventes 010
 
et un utilisateur "administrateur des ventes" :
membre du groupe "ventes" et les droits "1__"
 
=> ainsi, on lorsqu'on calcule ses droits, on retoure 110 comme désiré.
 
l'intérêt du truc, c'est que lorsque tu as des droits plus complexes, et qu'un jour un groupe se voit octroyer un nouveau droit, alors il est propagé à tous les utilisateurs membres du groupe, y compris ceux à qui on a collé des droits spécifiques en plus.
 
idem, on peut avoir un groupe "administration" qui octroie les droits "111"
un utilisateur "administrateur des achats" peut alors se voir membre de ce groupe, mais avoir les droits suivants : "_0_" => on lui interdit explicitement l'accès aux modules des ventes, quelque soit son groupe. il se retrouve alors finalement avec ces droits : "101"
 
Perso, j'ai rien inventé hein... Les ACL Windows font leur preuves depuis plus de 15 ans et fonctionnent sur ce modèle (en plus complexe encore : octroyé/refusé/non paramétré, mais avec en plus la possibilité d'appartenir à plusieurs groupes simultanés et en cascades -groupe qui appartient à un groupe-. idem, un droit ne correspond pas à un "domaine" sous windows, mais à une action. et chaque élément attribue des droits pour une action donnée à des groupes/comptes donnés. bref, ça va bien plus loin, mais ça commence à faire un peu complexe pour un simple site web. les valeurs "refusé" prenent alors le dessus sur toutes les autres autorisations quelles que soient le niveau de chaque)
 
par exemple, les groupes :
"ventes"
"achats"
 
le groupe "admin" membre de "ventes" et "achats"
 
l'utilisateur "root" membre de "admin"
 
sur la page, je mets :
"ventes" : lecture autorisée / écriture interdite
"root" : lecture autorisée / écriture autorisée
 
=> "root" ne peut pas écrire, car il est indirectement membre de "ventes" à qui on interdit l'accès.
 
on modifie :
"ventes" : lecture autorisée / écriture non spécifiée
"admin" : lecture autorisée / écriture autorisée
"root" : droits non spécifiés
 
=> "root" peut écrire, car il est membre de "admin" qui est autorisée, et aucun autre droit ne va à l'encontre de cette autorisation
=> par contre, un membre de "ventes" uniquement ne pourra pas écrire, car en l'absence d'autorisation, on n'octroie pas le droit
 
bon, par contre on voit que ça commence à devenir un peu compliqué juste pour un site web. ceci dit, c'est ce qu'il y a de mieux je pense parmis les solutions "simples".

Bon, que Windows utilise ce système depuis 15 ans, ça me fait ni chaud ni froid... C'est pas comme si Microsoft était une référence en terme d'efficacité, de performances et de simplicité...    
 
Mais j'ai compris à quoi ça servait, merci pour l'explication.   Par contre je pense que pour un site web, ça n'est pas très utile d'avoir un niveau de granularité aussi fin sur les permissions. Se limiter à une notion de "groupe" (qu'on pourrait aussi appeller "profil" ) pour définir des permissions pour un ensemble d'utilisateur c'est beaucoup plus facile à gérer (aussi bien pour le développeur que pour l'utilisateur). Par exemple : tu veux créer un utilisateur "administrateur des ventes" ? Crée un profil "Administrateur des ventes", etc.

Ben pourtant, en ce qui concerne les ACL, c'est bien un truc que le monde d'Unix a bien dû reconnaître qu'il lui manquait... C'est d'ailleurs pas pour rien si maintenant elles ont été portées sous Linux (avec quelques évolutions tant qu'à faire).
 
Sinon, pour un site où tu as généralement des autorisations assez basiques, je suis d'accord qu'aller jusqu'à ce niveau de détail c'est pas forcément très utile. En revanche, pour un CMS ou une GED, c'est extrêment utile au contraire. Ca évite d'avoir pour ainsi dire 1 groupe par utilisateur.

L ACL que tu decrit donne la lecture pour tout le monde et la modification pour ceux qui ont un bit de poids fort a 1.

Je trouve qu'elle est incomplete ...

hein ?

Merci MagicBuzz pour ces explications, je pense que c'est la solution que je vais utiliser, un peu sur le meme genre que la gestion des droits sous Unix.