Zend_ACL Limitation?

Question

J'envisage d'utiliser Zend_ACL. Cependant, pour moi, il semble que vous créiez des rôles et donniez ensuite ces rôles aux contrôleurs et aux actions auxquels ils peuvent ou ne peuvent pas accéder.

Cependant, pour moi cela semble assez limité. J'ai créé un système de permission d'utilisateur dans le passé où j'ai stocké le user_id, le module, le contrôleur et l'action qu'ils peuvent accéder, cependant je ne leur ai jamais donné un groupe. Par conséquent, c'était un par utilisateur, par module, par contrôleur, par action de base sur ce qu'ils pouvaient accéder.

Alors! Je me demandais si je voulais être moins limité par les groupes que je devrais donner à l'utilisateur un groupe et définir ces permissions de groupe par défaut. Ensuite, chargez mes rôles spécifiques à l'utilisateur et écrivez les rôles définis par le groupe par défaut: est-ce ainsi que vous le feriez?

Answer 1

Merci pour vos commentaires les gars, mais j'ai décidé de créer le mien. Dans le cas où quelqu'un est intéressé:

public function verify($controller=NULL, $action='index', $module='administration') { 

    if ((isset($this->object[$module]['all']) && is_string($this->object[$module]['all'])) || isset($this->object[$module][$controller][$action]) || (isset($this->object[$module][$controller]) && is_string($this->object[$module][$controller]))) { 
     return true; 
    } 
} 

public static function check($values) { 

    $module   = $values['module']  ? $values['module']  : 'administration'; 
    $controller  = $values['controller'] ? $values['controller'] : 'index'; 
    $action   = $values['action']  ? $values['action']  : 'index'; 
    $user_id  = $values['user_id']; 

    $db = Zend_Registry::get('dbAdapter'); 
    $query = $db->prepare(" 
     SELECT * 
     FROM `".self::table_name."` 
     WHERE 
      (
       (`module` = :module AND `controller` = :controller AND `action` = :action) OR 
       (`module` = :module_2 AND `controller` = :controller_2 AND `action` = '') OR 
       (`module` = :module_3 AND `controller` = '' AND `action` = '') 
      ) 
     AND enabled = 1 
     AND user_id = :user_id  
     "); 

    $query->bindValue('module',   $module); 
    $query->bindValue('module_2',  $module); 
    $query->bindValue('module_3',  $module); 
    $query->bindValue('controller',  $controller); 
    $query->bindValue('controller_2', $controller); 
    $query->bindValue('action',   $action); 
    $query->bindValue('user_id',  $user_id); 

    $query->execute(); 
    $item = $query->fetch(PDO::FETCH_OBJ); 
    $query->closeCursor(); 

    if (is_object($item)) { 
     return $item; 
    } else { 
     throw new exception("Could not load user permission for this page ($module, $controller, $action)"); 
    } 
} 

et dans la vue:

<?php if ($this->user_permissions->verify('movie')) { ?> 
     <li class="parent"> 
      <img src="/design/images/icon/dvd.png" /> <span class="highlighter"><a href="/administration/movie/index">Movie</a></span> 
      <?php if ($this->user_permissions->verify('movie', 'add')) { ?> 
       | <a href="/administration/movie/add">Add</a> 
      <?php } ?> 
      <?php if ($this->user_permissions->verify('movie', 'featured')) { ?> 
       <ul> 
        <li> 
         <img src="/design/images/icon/order.png" /> <a href="/administration/movie/featured">Order Featured</a> 
        </li> 
       </ul> 
      <?php } ?> 
     </li> 
    <?php } ?> 

Answer 2

Vous êtes sur la bonne voie.

Il n'y a pas de concept de "groupe" ou d '"utilisateur", strictement défini.

Vous avez juste des rôles. Vous pourriez avoir un rôle comme "éditeurs", qui peuvent accéder à certaines ressources (comme une action particulière, ou même un objet "article"). Vous pourriez également avoir un rôle comme user_1234, qui pourrait avoir des règles supplémentaires.

Vous donnerais les deux rôles à l'utilisateur avec id 1234.

Answer 3

En réponse à ce qui précède (ma réponse est longue)

Oui, je ne suis pas un grand fan de le faire comme cette. Id ont plutôt un tableau chargé pour cet utilisateur spécifique:

$item['Movie'] = 1; 
$item['Movie']['manage']['edit'] = 0; 

Ensuite, faites un plug-in, qui charge les autorisations (de la db, dans un tableau) se penche sur le module/contrôleur/action en cours et les chèques. Puis, dans mon bootstrap, si c'est faux, lancez une exception. (Gardez à l'esprit, ceci est pour la zone d'administration de mon site, pas le frontal, donc je ne suis pas préoccupé par un accès utilisateur général.)

Aussi je passerais ce tableau sur la vue et faire simple si des déclarations sur les liens:.

<?php if ($this->userPermission['Movie']['manage']['edit'])) { ?> 
<a href="/administration/Movie/manage/edit/id/1">Edit Movie</a><?php } ?> 

L'inconvénient étant que si cette méthode contrôleur jamais changé, je dois modifier les modèles Cependant, je l'ai vu aucune vue Zend_Acl implimentation des tutoriels que j'ai lu donc je Je ne sais pas si c'est très différent de ce que je ferais là

Answer 4

J'ai demandé un very similar question quand j'ai commencé à utiliser Zend_Acl. s ma solution avec du code. Cela pourrait vous aider. :)

Answer 5

Vous n'êtes en aucun cas limité à l'utilisation du système de rôle pour désigner des groupes dans Zend_Acl.

Par exemple:

Dans une application, j'ai mon objet utilisateur de base, mettre en œuvre Zend_Acl_Role_Interface qui, dans ce cas, renvoie une chaîne qui est spécifique pour l'utilisateur. Par souci de simplicité, disons simplement quelque chose comme user-1, où la partie numérique est l'ID unique de l'utilisateur.

Lorsque l'objet utilisateur est initialisé, il s'ajoute à l'ACL, le rôle spécifique de l'utilisateur héritant d'un rôle plus générique (semblable à un groupe.):

if(!$acl->hasRole($this)) { 
    $acl->addRole($this, $this->role); // Let's say role == 'member' here 
} 

Cela vous permet de définir général règles pour le rôle parent (ou rôles, vous pouvez passer un tableau en tant que deuxième argument à addRole, pour avoir plusieurs parents.) Rappelez-vous que les rôles ont une lignée tout le long de l'arbre, donc le rôle parent dans ce cas peut aussi Donc, pour illustrer la flexibilité ici, supposons que cette base ACL mis en place (Tout cela est théorique, je suis wri ting ce dans le seul but de cette réponse):

$acl->addRole('guest'); 
$acl->addRole('member', 'guest'); 

$acl->allow('guest', 'comments', 'read'); 
$acl->allow('member', 'comments', 'write'); 

$user = $My_User_Model->find(1); 
$acl->allow($user, 'comments', 'moderate'); 



$acl->isAllowed($user, 'comments', 'read'); // true 
$acl->isAllowed($user, 'comments', 'write'); // true 
$acl->isAllowed($user, 'comments', 'moderate'); // true 

$acl->isAllowed('member', 'comments', 'moderate'); // false 

Et ainsi de suite ...

La beauté des composants de Zend Framework est que vous n'êtes pas du tout limité à les utiliser dans un spécifique façon. Oui, même si cela peut parfois être décourageant et nécessite souvent un peu plus de temps pour la planification initiale et la mise en œuvre, c'est formidable à long terme.

En outre, personnellement, je ne suis pas un fan du mappage direct des privilèges ACL à un contrôleur/construction d'action. Mais c'est une conversation totalement différente.