Discussion :

[anikon]

Bonjour,

est ce que quelqu'un pourrait éclairer ma lanterne concernant les ACL. Je viens de créer une petit appli assez simple mais je rencontre quelques soucis sur les ACL.

J'ai bien entendu lu la doc, suivi le tutoriel et recherché sur le web mais on retrouve le meme tutoriel copié collé à toutes les sauces...

Dans mes AROS c'est très simples j'ai 2 Groupes (admin et utilisateurs) et une poignée d'utilisateurs.

Dans mes ACOS, je ne vais pas tout lister mais j'ai créé :
-root/controllers
-controllers/Sites
-Sites/view
-Sites/index
-Sites/add
-Sites/edit
-Sites/delete

Dans AROS_ACOS, j'ai bien une règle sur mes Sites, les utilisateurs peuvent créer et voir mais pas modifier et supprimer donc :
create: 1
read : 1
update : -1
delete : -1

Malheureusement ca ne fonctionne pas comme prévu et d'ailleurs je ne comprend pas comment le système détermine quelles actions du controller sont un read ou un update ou un delete... Et si je créer une action personnalisée dans quelle action du CRUD va t'elle se retrouvée ???

Je suis un peu perdu car il est bien expliqué de créer chaque actions (index,add,edit,delete) dans les ACOS mais coté AROS déjà c'est create,read,update,delete et les actions view et index sont toutes deux des read...

Je dois donc me retrouver par exemple avec l'action "add" du controller "Sites" avec des droits add,edit,delete,read alors que ca n'est qu'un create...

Bref j'ai du loupé un truc ?!

[anikon]

Je me répond pour essayer de faire avancer le problème et cela peux servir à d'autres. J'ai découvert un fonctionnement particulier de l'ACL.

Pour essayer d'être clair dans mes explications, je vais représenter quelques enregistrement de la base ACL :

AROS :

id | parent_id | model .....
--------------------------
2 | NULL | Group .....

ACOS :

id | parent_id |model | foreign_key | alias | lft | rght
----------------------------------------------------------
1 | NULL |NULL | NULL | controllers | 1 | 62
.......
27 | 1 | NULL | NULL | Sites | 38 | 49
28 | 1 | NULL | NULL | index | 39 | 40
29 | 1 | NULL | NULL | view | 41 | 42
30 | 1 | NULL | NULL | add | 43 | 44
31 | 1 | NULL | NULL | edit | 45 | 46
32 | 1 | NULL | NULL | delete | 47 | 48

AROS_ACOS :

id | aro_id | aco_id | _create | _read | _update | _delete
--------------------------------------------------------------
6 | 2 | 1 | -1 | -1 | -1 | -1
7 | 2 | 27 | 1 | 1 | -1 | -1

Avec cette config je pensais "bêtement" que les actions edit et delete de mon controller Sites seraient interdites. Mais en fait c'est tout le controller qui était interdit !!!

De plus je ne comprenais pas pourquoi devoir référencer toutes les actions dans les acos alors que nul part il n'est précisé la liaison entre les noms d'actions du controller (edit, add, index, view ) et celle du model (read, create, update) bref, j'ai fais un test en ajoutant ceci dans AROS_ACOS :

7 | 2 | 27 | 1 | 1 | 1 | 1
9 | 2 | 32 | -1 | -1 | -1 | -1
10 | 2 | 31 | -1 | -1 | -1 | -1

Rappel : 32 et 31 sont edit et delete dans la table ACOS

Et la magie, tout fonctionne comme prévue...

Mon problème est donc résolu techniquement mais personnellement j'ai un gros soucis car je n'ai pas compris l'intérêt des champs _read, _create, _update, _delete ??? Ils doivent être tous les 4 à 1 ou -1 et affecter à une action en particulier d'ou la question de l'utilité de 4 champs ???

Si quelqu’un à un une expérience à ce sujet je suis preneur.

Bonne journée à tous.