les ACL en PHP

Je me réponds à moi même :p

J'ai fini, en lisant pas mal de code des frameworks existants (en l'occurrence Zend et CakePHP), à créer une petite classe PHP pour gérer les droits/ACL avec système d'héritage.
Si y'a des gens intéressé, je peux poster mon code (après avoir mis quelques commentaires pour comprendre/adapter) !
Par contre tuto texte car je suis pas aussi alaise que notre gourou Mr Grafikart ;)

hello matthieuy , moi ca m’intéresse de voir ton code surtout si tu t'es inspiré de fwk comme zend et cacke poste nous ca sur git ;) tu aura un retour sur ton code
Merci

pas mal pour un premier dépôt , c'est propre je parle de la doc aussi c'est très bien , moi le seul problème que j'ai avec ce code c'est que en tant qu’administrateur réseau quand je parle Acl je parle de quelque chose d'un peut plus complexe en effet mais dans le sens ou l'autorisation seraient des autorisation différents , exemple Autoriser la lecture d'une news ou autoriser l'écriture , ou encore l’édition d'une news {allowRead, AllowRwite, AllowEdit,AllowDelete } , mais je pense qu'il est possible d'améliorer ta classe dans ce sens
Mais si non beau travail ;)

toujours en tant qu’administrateurs les acls sont en fait appliqué sur les ressources et non sur les utilisateurs c'est l'impression que donne la lecture de cette ligne $acl->allow('papy', 'chezPapy'); c'est popy qui est autorisé a la ressources ,
moi ton code m'inspire une ACL comme ça
$acl=ressource('new')->allow('admin')->right($read=true,$right=true,$delete=true);
ou encore en CHMOD
$acl=ressource('new')->allow('admin')->right(777);

Merci pour le retour ;)
J'ai mis un système de scope (ou module) pour mes besoins de séparer les droits donc normalement tu dois pouvoir (si j'ai bien compris ce que tu souhaitais)

// Séparation des droits par scope/module (ici un module "news" et un "article")
$acl->addResource(array('lire', 'ecrire', 'editer', 'supprimer'), 'news');
$acl->addResource(array('lire', 'ecrire', 'editer', 'supprimer'), 'articles');
// Exemple d'autorisation pour un rédacteur (role) sur le module "news"
$acl->allow('redacteur', array('lire', 'ecrire', 'editer'), 'news');

Comme tu le dis, y'a pas mal de chose à faire évoluer.
Je pense que les prochaines évolutions seront surtout pour serializer/stocker les droits par groupe ou utilisateur (role) et pouvoir les injecter au chargement (via un json ou BDD par exemple).
Mais je vais voir pour mettre en place un système comme tu l'expliques (pas de chmod car j'en n'ai pas l'utilité) mais un truc du genre :
$acl->getRessource('news')->allow('admin')->right('lire');
A voir...

pour le module c'est pas mal
j'ai pas asse regardé du coté du code, ton second exemple m'a convaincu, tu viens de l'ajouter dans la doc celui la ;)

bon courage pour le sauvegarde DB surtout pour l'héritage !

ouais, il n'était pas dans la doc donc du coup je l'ai rajouté ;)

j'ai pris le temps de voir le code mais a mon avis , on a plus de chances d'avoir plusieurs rôles avec un parent et rarement l'inverse , exemple le rôle admin peut avoir plusieurs admin mais rarement un user qui soit enfant de admin,invete,...

C'est pas faux !
J'suis entrain de recoder un truc un peu plus complet avec 3 classes : Acl, Resource, Role
J'ai mis en place ton idée du coup on peut appliquer une règle de 3 manières différentes :

<?php
// Définition des éléments
$acl = new Acl();
$admin = new Role('admin');
$resource = new Resource('supprimer', 'news');
// A partir de l'acl
$acl->allow($admin, $resource);
// ou à partir du role
$admin->allow($resource);
// ou a partir de la resource
$resource->allow($admin);

C'était un peu ça l'idée, non ?

Par contre comme j'ai tout recommencé, je fais un raz du dépôt git ou je créer un autre dépôt,...
C'est quoi le mieux ? (oui je suis un noob sur Github :D)

pas mal du tout , en moi qui avait changé fait un autre commint ;(
alors je pense que celle ci est une version avancé ce qu'il faut faire c'est laisser l’ancienne car elle est basique et elle restera utile pour les autres surtout si tu met la doc les commentaires en anglais
après , le gros d'une ACL le concept a respecter c'est de soit faire passer les ACL dans un ordre précis celui de leurs insertion , mais moi je te conseil la façon stricte de chez micorosoft qui fait passer les les Allow en suite les Deny et la fin un deny all par exemple pour ne pas autorise les cas omis
comme quoi ont en apprend tous les jours nous sommes tous des noobs ^^

Ah oui dans le précédent commit j'ai corrigé ce qui pourrait devenir un bug , un role ne dois pas hériter de luis même

J'ai suivi ton conseil et fait un 2ème dépôt avec un système un peu plus complet

• 3 classes : Acl, Resource, Role

• Composer + PSR-2

• Doc et commentaires en anglais

C'est loin d'être complet mais c'est fonctionnel
Dispo ici : https://github.com/matthieuy/acl-manager

beau travail , j'avais vu ce matin j'ai fait un fork ^^ , il y a de petites erreurs d'ang1ais dans la doc mais ferais un pull plus tard , en suite une idée sympa a mettre en place serait des groupes par défaut , ou sa pourrait être aussi des scopes , on peut imaginer 3 groupes
Master -> lecture modification suppression
Edit-> lecture modification
ReadOnly-> lecture seule

mettre une sorte de logique standard d'utilisation genre on applique une acl a un groupe et tous membres de ce groupe auront les droits du groupe en question , plutôt que d'avoir un rôle parent qui risque d'amener des confusion et des question genre qui est capable de quoi au final ?
toi même tu évite ça, tu as mis en place le système de debug qui affiche un résultat plutôt sympa mais je trouve que des groupes de droits c'est plus simple a gérer que des rôles parents enfants
et puis si on a un membre qui appartient a deux groupes on applique le plus restreins des deux
voila l'idée s'éloigne peut être de celle du départ mais voila
BRAVO ;)

nouveau pull , mais la j'ai ajouter les alias pour les namespaces rapidement mais j'ai pas testé ca avec l'autoloader de composer faut essayer , et puis bug dans addRole corrigé

Ouais, la doc ce n'est pas vraiment mon fort, alors en anglais... :-/

Pour l'idée des groupes pré-définit, je pense que le mieux est de surcharger/étendre la classe "Acl" avec par exemple une méthode "init()".
Ça permettrait d'adapter selon le projet.

Après pour mettre une ACL directement sur une ressource, bonne idée : à voir comment le mettre en place

// Un truc du genre
$resource->allowForAll();
$resource->denyForAll();

Pour le membre qui appartient à 2 groupes, c'est vrai qu'il est plus logique d'appliquer le plus restreins des deux.
Ce n'est pas le cas actuellement. Dans mes tests, je rajoute une acl sur le role "enfant" pour préciser l'accès.
Il y a sans doute moyen de faire plus simple !

A voir aussi si il n'y a pas moyen de mettre une méthode simple et assez générique pour rattacher un utilisateur ou autre chose (avec son id par exemple) à un rôle (On retrouverai ainsi ton système de groupe).

J'vais surement refaire une méthode "debug()" car bien pratique pour les test ;)

PS : Ce sujet devrait peut-être être déplacer dans une autre rubrique du forum ! Si un modérateur lit ce post ;)

Edit : Arff... je viens de voir ton pull, j'avais déjà corrigé une partie de ces erreurs (mais pas toutes). Du coup faut que je vois comment "merge avec les conflits" :D

oui le post n'est plus trop a sa place , je te laisse finaliser un peut ton travail au lieux te mettre des battons dans les roues avec mes pull en tout cas ca m'a fait plaisir de contribuer ne serait-ce qu'un chouia a ton dépôt

Tu ne me mets pas des battons dans les roues c'est jusque que je galère avec git :-/ (j'utilise subversion au taff donc j'suis un peu perdu).
En tout cas, merci à toi pour ta contribution et tes idées et n'hésites pas si tu as d'autres modifs ;)

je mettrais plus de mon temps libre dans le projet , faudra que je lise bien tout le code , pour contribuer tout en respectant l'idée principal ;)