documentation/manual/fr/tutorials/multiuser-authorization.xml

   1 <?xml version="1.0" encoding="UTF-8"?>
   2 <!-- EN-Revision: 20876 -->
   3 <!-- Reviewed: no -->
   4 <sect1 id="learning.multiuser.authorization">
   5     <title>Fabriquer un système de gestion d'autorisations avec Zend Framework</title>
   6
   7     <sect2 id="learning.multiuser.authorization.intro">
   8         <title>Introduction à l'autorisation</title>
   9
  10         <para>
  11             Après qu'un utilisateur se soit authentifié, une application peut proposer différentes
  12             règles d'accès à ses différentes ressources (parties). Le procédé qui consiste à savoir
  13             "qui a le droit de faire quoi" est nommé "gestion des autorisations". Dans sa forme la
  14             plus simple l'autorisation est la composition de trois facteurs:
  15         </para>
  16
  17         <itemizedlist>
  18             <listitem>
  19                 <para>
  20                     l'identitié de la personne souhaitant des droits - le rôle (qui?)
  21                 </para>
  22             </listitem>
  23
  24             <listitem>
  25                 <para>
  26                     la ressource demandée (sur quoi?)
  27                 </para>
  28             </listitem>
  29
  30             <listitem>
  31                 <para>
  32                     et optionnellement le privilège - le droit (quoi?)
  33                 </para>
  34             </listitem>
  35         </itemizedlist>
  36
  37         <para>
  38             Dans Zend Framework, le composant <classname>Zend_Acl</classname> vous propose de créer
  39             ces trois entités remarquables, de les associer et de les interroger dans le futur.
  40         </para>
  41
  42     </sect2>
  43
  44     <sect2 id="learning.multiuser.authorization.basic-usage">
  45         <title>Utilisation de base de Zend_Acl</title>
  46
  47 <!-- explain the interaction with a User object, how -->
  48
  49         <para>
  50             En utilisant <classname>Zend_Acl</classname>, n'importe quel modèle peut servir de rôle
  51             ou de ressource en implémentant l'interface adéquate. Pour créer des rôles, implémentez
  52             <classname>Zend_Acl_Role_Interface</classname>, qui définit la méthode
  53             <methodname>getRoleId()</methodname>. Pour créer des ressources, implémentez
  54             <classname>Zend_Acl_Resource_Interface</classname> qui définit la méthode
  55             <methodname>getResourceId()</methodname>.
  56         </para>
  57
  58         <para>
  59             Nous allons faire une démonstration avec un modèle simple. On peut le relier avec notre
  60             système d'<acronym>ACL</acronym> en implémentant
  61             <classname>Zend_Acl_Role_Interface</classname>. La méthode
  62             <methodname>getRoleId()</methodname> retournera "guest" lorsque l'ID est inconnu,
  63             ou l'ID du rôle lorsque celui-ci aura été affecté. Cette valeur peut provenir de n'importe
  64             où, probablement qu'elle proviendra d'une définition faite en base de données.
  65         </para>
  66
  67         <programlisting language="php"><![CDATA[
  68 class Default_Model_User implements Zend_Acl_Role_Interface
  69 {
  70     protected $_aclRoleId = null;
  71
  72     public function getRoleId()
  73     {
  74         if ($this->_aclRoleId == null) {
  75             return 'guest';
  76         }
  77
  78         return $this->_aclRoleId;
  79     }
  80 }
  81 ]]></programlisting>
  82
  83         <para>
  84             Le concept des utilisateurs ayant des rôles est simple à comprendre, mais l'application
  85             peut consommer plusieurs modèles et en retrouver des "ressources" qui seront
  86             consommables par les rôles. Nous utiliserons simplement des billets de blog comme
  87             ressources dans nos exemples, et comme les ressources sont des objets, nous ferons
  88             en sorte que l'ID d'un billet blog soir 'blogPost', naturellement cette valeur peut
  89             être calculée dynamiquement en fonction du besoin.
  90         </para>
  91
  92         <programlisting language="php"><![CDATA[
  93 class Default_Model_BlogPost implements Zend_Acl_Resource_Interface
  94 {
  95     public function getResourceId()
  96     {
  97         return 'blogPost';
  98     }
  99 }
 100 ]]></programlisting>
 101
 102         <para>
 103             Maintenant que nous avons au minimum un rôle et une ressource, définissons règles qui les
 104             lient. Ces règles seront lues lorsque le système recevra une requête d'acl demandant ce
 105             qu'il est possible de faire avec tel rôle, telle ressource et éventuellement tel privilège.
 106         </para>
 107
 108         <para>
 109             Imaginons les règles suivantes:
 110         </para>
 111
 112         <programlisting language="php"><![CDATA[
 113 $acl = new Zend_Acl();
 114
 115 // mise en place des rôles
 116 $acl->addRole('guest');
 117 // owner hérite du rôle guest
 118 $acl->addRole('owner', 'guest');
 119
 120 // ajout de ressources
 121 $acl->addResource('blogPost');
 122
 123 // ajout de privilèges liant des rôles et des ressources
 124 $acl->allow('guest', 'blogPost', 'view');
 125 $acl->allow('owner', 'blogPost', 'post');
 126 $acl->allow('owner', 'blogPost', 'publish');
 127 ]]></programlisting>
 128
 129         <para>
 130             Les règles ci-dessus sont très simples: deux rôles "guest"(invité) et "owner"
 131             (propriétaire), et une ressource "blogPost"(billet). Les invités sont autorisés
 132             à voir les billets, les propriétaires peuvent poster et publier des billets. Pour
 133             requêter le système, procédez alors comme suit:
 134         </para>
 135
 136         <programlisting language="php"><![CDATA[
 137 // Imaginons que le modèle User soit de type "guest"
 138 $guestUser = new Default_Model_User();
 139 $ownerUser = new Default_Model_Owner('OwnersUsername');
 140
 141 $post = new Default_Model_BlogPost();
 142
 143 $acl->isAllowed($guestUser, $post, 'view'); // true
 144 $acl->isAllowed($ownerUser, $post, 'view'); // true
 145 $acl->isAllowed($guestUser, $post, 'post'); // false
 146 $acl->isAllowed($ownerUser, $post, 'post'); // true
 147 ]]></programlisting>
 148
 149         <para>
 150             Comme vous pouvez le voir le système répond comme il faut dans la mesure où les
 151             invités peuvent lire les billets mais seuls les propriétaires peuvent en ajouter.
 152             Cependant ce système peut sembler manquer de dynamisme. Comment vérifier qu'un
 153             utilisateur spécifique est bien propriétaire d'un billet spécifique avant de
 154             l'autoriser à le publier ? Autrement dit, on veut s'assurer que seuls les
 155             propriétaires des billets peuvent publier ceux-ci, et pas ceux des autres.
 156         </para>
 157
 158         <para>
 159             C'est là qu'entrent en jeu les assertions. Les assertions sont des vérifications
 160             supplémentaires à effectuer en même temps que la vérification de la règle d'acl.
 161             Ce sont des objets. Utilisons notre exemple avec une assertion:
 162         </para>
 163
 164         <programlisting language="php"><![CDATA[
 165 class OwnerCanPublishBlogPostAssertion implements Zend_Acl_Assert_Interface
 166 {
 167     /**
 168      * Cette assertion va recevoir le User et le BlogPost actuels.
 169      *
 170      * @param Zend_Acl $acl
 171      * @param Zend_Acl_Role_Interface $user
 172      * @param Zend_Acl_Resource_Interface $blogPost
 173      * @param $privilege
 174      * @return bool
 175      */
 176     public function assert(Zend_Acl $acl,
 177                            Zend_Acl_Role_Interface $user = null,
 178                            Zend_Acl_Resource_Interface $blogPost = null,
 179                            $privilege = null)
 180     {
 181         if (!$user instanceof Default_Model_User) {
 182             throw new Exception(__CLASS__
 183                               . '::'
 184                               . __METHOD__
 185                               . ' s'attend à un rôle'
 186                               . ' instance de User');
 187         }
 188
 189         if (!$blogPost instanceof Default_Model_BlogPost) {
 190             throw new Exception(__CLASS__
 191                               . '::'
 192                               . __METHOD__
 193                               . ' s'attend à un rôle'
 194                               . ' instance de BlogPost');
 195         }
 196
 197         // Si le rôle est publisher, il peut toujours modifier son billet
 198         if ($user->getRoleId() == 'publisher') {
 199             return true;
 200         }
 201
 202         // vérifions que qui que ce soit, il modifie uniquement ses propres billets
 203         if ($user->id != null && $blogPost->ownerUserId == $user->id) {
 204             return true;
 205         } else {
 206             return false;
 207         }
 208     }
 209 }
 210 ]]></programlisting>
 211
 212         <para>
 213             Pour faire intervenir l'assertion dans les <acronym>ACL</acronym>, nous les utilisons comme ceci:
 214         </para>
 215
 216         <programlisting language="php"><![CDATA[
 217 // remplacez ceci:
 218 //   $acl->allow('owner', 'blogPost', 'publish');
 219 // par cela:
 220 $acl->allow('owner',
 221             'blogPost',
 222             'publish',
 223             new OwnerCanPublishBlogPostAssertion());
 224
 225 // ajoutons aussi le rôle "publisher" qui a accès à tout
 226 $acl->allow('publisher', 'blogPost', 'publish');
 227 ]]></programlisting>
 228
 229         <para>
 230             Maintenant, dès que l'<acronym>ACL</acronym> est consultée pour savoir si un propriétaire
 231             peut publier un billet, cette assertion sera vérifiée. Elle s'assure que sauf si le rôle
 232             est 'publisher' le propriétaire a bien écrit le billet. Dans cet exemple, nous vérifions
 233             pour savoir si l'attribut <property>ownerUserId</property> du billet correspond à
 234             l'identifiant de l'utilisateur en question.
 235         </para>
 236     </sect2>
 237 </sect1>