2010-06-21 5 views
1

Je travaille sur une application qui aura 6 groupes ARO afin de couvrir le spectre des autorisations requises. Il est vraiment préférable d'avoir des méthodes * _add, * _edit, * _index, * _view, etc. Cela ressemble à un peu de surcharge de code et de maux de tête de maintenance. Le « moins cher » comme je peux imaginer pour gérer avec routage est quelque chose comme:CakePHP w/ACL: La meilleure pratique pour de nombreux groupes est le routage?

// core: edit 
function _edit($id = null) 
{ 
    // do stuff 
} 

function admin_edit($id = null) 
{ 
    $this->_edit($id); 
} 

function manager_edit($id = null) 
{ 
    $this->_edit($id); 
} 

function clerk_edit($id = null) 
{ 
    $this->_edit($id); 
} 

/* ...and on and on... */ 

et Toss des restrictions si nécessaire pour, par exemple, un groupe étant autorisé à posséder des éléments de ne modifier utilisateur, ou quelque chose de similaire.

Y at-il une autre technique recommandée ou est-ce vraiment la meilleure pratique?

+0

Vous pouvez vérifier cela - http://stackoverflow.com/questions/54230/cakephp-acl-database-setup-aro-aco-structure – bancer

+0

Je ne vais pas pour la «meilleure pratique», mais si Je l'ai fait, ce ne serait pas un. – Leo

+0

Parfois, il est utile de filtrer les utilisateurs. Je le fais dans la méthode beforeRender de app_controller pour définir certaines variables d'affichage. $ usersIndexAllowed = $ this-> Acl-> check ($ utilisateur, "users/index"); $ configureAllowed = $ this-> Acl-> check ($ utilisateur, "siteAdmins/configure"); $ this-> set (compact ('usersIndexAllowed', 'configureAllowed')); – Leo

Répondre

0

Vraisemblablement, vous voulez offrir des fonctionnalités différentes pour chaque groupe?

Si ce n'est pas le cas, il n'y a pas besoin de méthodes CRUD différentes pour chaque groupe.

Si, en revanche, c'est le cas, examinez les instructions switch dans les méthodes CRUD pour déterminer qui a cette capacité.

Il n'est pas nécessaire d'avoir une méthode pour chaque groupe.

+0

Pas nécessairement différentes fonctionnalités en dehors de "propre" accès. Considérons cet exemple artificiel structure de privilège où les privilèges pile: clients: indice propre, vue propre, éditer ses propres commis: Index, ajouter gestionnaires: voir tous, éditer tous les admins: accès j'aurais fourni quelque chose comme ça dans le message original pour clarification. – tomws

+0

Merde ... vient de remarquer que n'a pas formaté comme prévu. Essayer encore. Clients: index propre, vue propre, modifier propre. Commis: indexer tout, ajouter. Managers: affichez tout, modifiez tout. Administrateurs: accès complet. – tomws

+0

J'ai l'idée [je ne pense pas que vous pouvez mettre en forme des commentaires]. Je ferais (et l'ai fait) comme je le suggère. Utilisez la liste de contrôle d'accès pour filtrer l'accès à la méthode, puis affinez l'accès à l'intérieur de cette méthode en définissant un commutateur conditionnel, ou en fonction de vos préférences. – Leo

Questions connexes