Reflexion sur la gestion des Acl

Nani desu ka? 

Depuis peu je retouche l'ACL sur cakephp 1.2. En fait, le plus difficile est de se lancer. Aujourd'hui je comprends à peu près le fonctionnement néanmoins encore beaucoup de points restent obscurs. Ce n'est propre au framework cakephp mais plus au principe voir même de la philosophie "Acl".

Au commencement il y avait les Aro (les utilisateurs ou les groupes) : Ève. Ensuite arrivent les Aco (les contrôleurs, actions ou directement les objets ) : Adam (oui on sait tous que vous êtes manipulatrices). Il ne manque plus qu'un médiateur : la pomme (la table aros_acos dans cakephp qui définit les permissions : crud).

Je ne m'attarderai pas plus sur le concept (surtout que je dois très mal l'expliquer). 

Comment démarrer? 

La première fois sur cakephp 1.1 avec les tutoriaux ibm, avec le manuel de cake ou plus simplement avec le l'article de rtconner sur le bakery.

Mais voilà on aime l'aventure et ça fait un moment qu'on est passé sur cake 1.2.

Je me suis retrouvé dans un état d'excitation extrême à la lecture de l'article Gestion des droits d’accès par groupes d’utilisateurs. Simple et clair, je passe à l'action, j'intègre, j'adapte et je commence même un plugin.

Je recommande chaudement d'essayer acl manager plugin qui a la qualité d'être d'une simplicité enfantine à l'installation et à l'utilisation (un gosse qui sait faire un checkout sur svn tout de même) et permet en outre d'avoir un visu sur ce qu'il se passe.

Néanmoins quelque chose me titille.

Une usine à gaz? 

Peut être l'aurez-vous remarqué, dans tous les tutos présentés, aucun ne parle de suppression d'Aro ou Aco (sauf celui d'ibm). Et quand on veut gérer finement des droits il faut le faire en plein, c'est bien beau de créer des Objets dans tous les sens et d'indiquer les permissions mais on commence à administrer, modérer faire évoluer le contenu d'une application, on ne peut pas permettre de laisser des résidus qui pourrait mettre en péril la santé de notre chère appli.

Quand je disais que quelque chose me titille en fait je me suis rendu compte bien tard de cette évidence : les Objets sont créés en double dans l'application. Exemple :

• Un utilisateur dans la table users => un référent dans la table Aros.
• Un groupe dans la table groups => un référent dans la table Aros.
• Une action dans un controller => un référent dans la table Acos.
• Un produit dans la table products => un référent dans la table Acos.

Problème n°1 : on peut aisément créer un doublon : deux Objets ayant exactement les mêmes attributs.

Problème n°2 : comment je récupère l'id acl de l'objet que je veux supprimer?! 

Problème n°3 : ça y est je l'ai supprimé .... woops j'ai oublié de virer les anciennes permission :#

Solution : On s'en tape les burnes contre les murs.

Sauf que le jour où j'ai 10000 produits, 2000 utilisateurs, une tripoté de modérateurs à moitié abrutis (humour cynique), je préfère dès aujourd'hui le choix de l'optimisation. 

Mais ça se passe comment à coté?

On sait que différents système utilise l'Acl, gnu/Linux, Windows et sûrement plein d'autres. Cela me parait étrange que l'on s'extasie sur quelque chose qui peut aussi facilement partir en couille.

Et bien, sur nux les entités ne sont pas en doublon (déjà!), on a un compte unix unique (même qu'on le supprime jamais) des groupes uniques ... du coup on ne parle que d'Acl et par extrapolation des permissions.

Alors qu'est-ce qui ne va pas avec cakephp? Est-il trop souple : il permet de considérer des méthodes comme des Acos, il ne sais pas travailler directement avec les objets de la base de données... Il ne sait pas faire de relation direct entre un objet et son homologue aco ou aro?!

Solution? 

Je n'en vois qu'une, solution Unix style : ne jamais supprimer, autoriser seulement la désactivation.