Après qu'un utilisateur se soit authentifié, une application peut proposer différentes règles d'accès à ses différentes ressources (parties). Le procédé qui consiste à savoir "qui a le droit de faire quoi" est nommé "gestion des autorisations". Dans sa forme la plus simple l'autorisation est la composition de trois facteurs: l'identitié de la personne souhaitant des droits - le rôle (qui?) la ressource demandée (sur quoi?) et optionnellement le privilège - le droit (quoi?) Dans Zend Framework, le composant Zend_Acl vous propose de créer ces trois entités remarquables, de les associer et de les interroger dans le futur. En utilisant Zend_Acl, n'importe quel modèle peut servir de rôle ou de ressource en implémentant l'interface adéquate. Pour créer des rôles, implémentez Zend_Acl_Role_Interface, qui définit la méthode getRoleId(). Pour créer des ressources, implémentez Zend_Acl_Resource_Interface qui définit la méthode getResourceId(). Nous allons faire une démonstration avec un modèle simple. On peut le relier avec notre système d'ACL en implémentant Zend_Acl_Role_Interface. La méthode getRoleId() retournera "guest" lorsque l'ID est inconnu, ou l'ID du rôle lorsque celui-ci aura été affecté. Cette valeur peut provenir de n'importe où, probablement qu'elle proviendra d'une définition faite en base de données. _aclRoleId == null) { return 'guest'; } return $this->_aclRoleId; } } ]]> Le concept des utilisateurs ayant des rôles est simple à comprendre, mais l'application peut consommer plusieurs modèles et en retrouver des "ressources" qui seront consommables par les rôles. Nous utiliserons simplement des billets de blog comme ressources dans nos exemples, et comme les ressources sont des objets, nous ferons en sorte que l'ID d'un billet blog soir 'blogPost', naturellement cette valeur peut être calculée dynamiquement en fonction du besoin. Maintenant que nous avons au minimum un rôle et une ressource, définissons règles qui les lient. Ces règles seront lues lorsque le système recevra une requête d'acl demandant ce qu'il est possible de faire avec tel rôle, telle ressource et éventuellement tel privilège. Imaginons les règles suivantes: addRole('guest'); // owner hérite du rôle guest $acl->addRole('owner', 'guest'); // ajout de ressources $acl->addResource('blogPost'); // ajout de privilèges liant des rôles et des ressources $acl->allow('guest', 'blogPost', 'view'); $acl->allow('owner', 'blogPost', 'post'); $acl->allow('owner', 'blogPost', 'publish'); ]]> Les règles ci-dessus sont très simples: deux rôles "guest"(invité) et "owner" (propriétaire), et une ressource "blogPost"(billet). Les invités sont autorisés à voir les billets, les propriétaires peuvent poster et publier des billets. Pour requêter le système, procédez alors comme suit: isAllowed($guestUser, $post, 'view'); // true $acl->isAllowed($ownerUser, $post, 'view'); // true $acl->isAllowed($guestUser, $post, 'post'); // false $acl->isAllowed($ownerUser, $post, 'post'); // true ]]> Comme vous pouvez le voir le système répond comme il faut dans la mesure où les invités peuvent lire les billets mais seuls les propriétaires peuvent en ajouter. Cependant ce système peut sembler manquer de dynamisme. Comment vérifier qu'un utilisateur spécifique est bien propriétaire d'un billet spécifique avant de l'autoriser à le publier ? Autrement dit, on veut s'assurer que seuls les propriétaires des billets peuvent publier ceux-ci, et pas ceux des autres. C'est là qu'entrent en jeu les assertions. Les assertions sont des vérifications supplémentaires à effectuer en même temps que la vérification de la règle d'acl. Ce sont des objets. Utilisons notre exemple avec une assertion: getRoleId() == 'publisher') { return true; } // vérifions que qui que ce soit, il modifie uniquement ses propres billets if ($user->id != null && $blogPost->ownerUserId == $user->id) { return true; } else { return false; } } } ]]> Pour faire intervenir l'assertion dans les ACL, nous les utilisons comme ceci: allow('owner', 'blogPost', 'publish'); // par cela: $acl->allow('owner', 'blogPost', 'publish', new OwnerCanPublishBlogPostAssertion()); // ajoutons aussi le rôle "publisher" qui a accès à tout $acl->allow('publisher', 'blogPost', 'publish'); ]]> Maintenant, dès que l'ACL est consultée pour savoir si un propriétaire peut publier un billet, cette assertion sera vérifiée. Elle s'assure que sauf si le rôle est 'publisher' le propriétaire a bien écrit le billet. Dans cet exemple, nous vérifions pour savoir si l'attribut ownerUserId du billet correspond à l'identifiant de l'utilisateur en question.