Zend_Acl-Refining.xml 6.6 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199
  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <!-- EN-Revision: 15029 -->
  3. <!-- Reviewed: no -->
  4. <sect1 id="zend.acl.refining">
  5. <title>Verfeinern der Zugriffskontrolle</title>
  6. <sect2 id="zend.acl.refining.precise">
  7. <title>Präzise Zugangsbeschränkung</title>
  8. <para>
  9. Die grundlegende ACL, wie sie im <link linkend="zend.acl.introduction">vorherigen
  10. Kapitel</link> definiert ist, zeigt wie verschiedene Rechte für die gesamte ACL (alle
  11. Ressourcen) vergeben werden können. In der Praxis tendieren Zugangsbeschränkungen jedoch
  12. eher dahin, Ausnahmen und verschiedene Stufen von Komplexität zu haben. <classname>Zend_Acl</classname>
  13. erlaubt einem, diese Verfeinerungen auf einfache und flexible Weise zu bewerkstelligen.
  14. </para>
  15. <para>
  16. Für das Beispiel CMS wurde ermittelt, dass, während die 'staff' Gruppe die Bedürfnisse
  17. der überwiegenden Mehrheit der Benutzer abdeckt, es den Bedarf für eine neue 'marketing'
  18. Gruppe gibt, die Zugriff auf den Newsletter und die neuesten Nachrichten im CMS
  19. benötigen. Die Gruppe ist ziemlich unabhängig und wird die Möglichkeit haben, sowohl
  20. Newsletter als auch die neuesten Nachrichten zu veröffentlichen und zu archivieren.
  21. </para>
  22. <para>
  23. Zusätzlich wurde angefordert, dass es der 'staff' Gruppe erlaubt sein soll, die Nachrichten
  24. ansehen, aber nicht die neuesten Nachrichen überarbeiten zu können. Zuguterletzt soll
  25. es für jeden (Administratoren eingeschlossen) unmöglich sein, irgend eine
  26. Bekanntmachung zu archivieren, da diese sowieso nur eine Lebensdauer von 1 bis 2
  27. Tagen haben.
  28. </para>
  29. <para>
  30. Zuerst überarbeiten wir die Rollenregistrierung, um die Änderungen wider zu spiegeln.
  31. Wir haben ermittelt, dass die 'marketing' Gruppe die selben grundlegenden Rechte wie
  32. 'staff' hat, also definieren wir 'marketing' so, dass die Genehmigungen von 'staff'
  33. geerbt werden:
  34. </para>
  35. <programlisting role="php"><![CDATA[
  36. // Die neue Marketing Gruppe erbt Genehmigungen der Mitarbeiter
  37. $acl->addRole(new Zend_Acl_Role('marketing'), 'staff');
  38. ]]>
  39. </programlisting>
  40. <para>
  41. Als nächstes ist zu beachten, dass sich die obige Zugangsbeschränkung auf bestimmte
  42. Ressourcen bezieht (z.B. "newsletter", "lastest news", "announcement news"). Nun fügen
  43. wir die Ressourcen hinzu:
  44. </para>
  45. <programlisting role="php"><![CDATA[
  46. // Ressourcen für die Regeln erstellen
  47. // Newsletter
  48. $acl->add(new Zend_Acl_Resource('newsletter'));
  49. // Nachrichten
  50. $acl->add(new Zend_Acl_Resource('news'));
  51. // Neueste Nachrichten
  52. $acl->add(new Zend_Acl_Resource('latest'), 'news');
  53. // Bekanntmachungen
  54. $acl->add(new Zend_Acl_Resource('announcement'), 'news');
  55. ]]>
  56. </programlisting>
  57. <para>
  58. Nun ist es nur eine Frage der Definition für diese spezifischeren Regeln auf die
  59. Zielbereiche der ACL:
  60. </para>
  61. <programlisting role="php"><![CDATA[
  62. // Marketing muss Newsletter und die neuesten Nachrichten veröffentlichen
  63. // und archivieren können
  64. $acl->allow('marketing',
  65. array('newsletter', 'latest'),
  66. array('publish', 'archive'));
  67. // Staff (und Marketing durch die Vererbung), wird die Erlaubnis verweigert,
  68. // die neuesten Nachrichten überarbeiten zu können
  69. $acl->deny('staff', 'latest', 'revise');
  70. // Jedem (inklusive der Administratoren) wird die Erlaubnis verweigert,
  71. // Bekanntmachungsnachricht zu archivieren
  72. $acl->deny(null, 'announcement', 'archive');
  73. ]]>
  74. </programlisting>
  75. <para>
  76. Wir können nun die ACL abfragen hinsichtlich der letzten Änderungen
  77. </para>
  78. <programlisting role="php"><![CDATA[
  79. echo $acl->isAllowed('staff', 'newsletter', 'publish') ?
  80. "allowed" : "denied";
  81. // verweigert
  82. echo $acl->isAllowed('marketing', 'newsletter', 'publish') ?
  83. "allowed" : "denied";
  84. // erlaubt
  85. echo $acl->isAllowed('staff', 'latest', 'publish') ?
  86. "allowed" : "denied";
  87. // verweigert
  88. echo $acl->isAllowed('marketing', 'latest', 'publish') ?
  89. "allowed" : "denied";
  90. // erlaubt
  91. echo $acl->isAllowed('marketing', 'latest', 'archive') ?
  92. "allowed" : "denied";
  93. // erlaubt
  94. echo $acl->isAllowed('marketing', 'latest', 'revise') ?
  95. "allowed" : "denied";
  96. // verweigert
  97. echo $acl->isAllowed('editor', 'announcement', 'archive') ?
  98. "allowed" : "denied";
  99. // verweigert
  100. echo $acl->isAllowed('administrator', 'announcement', 'archive') ?
  101. "allowed" : "denied";
  102. // verweigert
  103. ]]>
  104. </programlisting>
  105. </sect2>
  106. <sect2 id="zend.acl.refining.removing">
  107. <title>Zugangsbeschränkungen entfernen</title>
  108. <para>
  109. Um eine oder mehrere Zugangsregel von der ACL zu entfernen, verwendet man einfach die
  110. vorhandenen <code>removeAllow()</code> oder <code>removeDeny()</code> Methoden. Wie bei
  111. <code>allow()</code> und <code>deny()</code> kann man den <code>null</code> Wert
  112. übergeben, um die Anwendung auf alle Rollen, Ressourcen und / oder Rechte anzuzeigen:
  113. </para>
  114. <programlisting role="php"><![CDATA[
  115. // Entferne die Verweigerung, die letzten Nachrichten zu überarbeiten für
  116. // die Mitarbeiter (und Marketing durch die Vererbung)
  117. $acl->removeDeny('staff', 'latest', 'revise');
  118. echo $acl->isAllowed('marketing', 'latest', 'revise') ?
  119. "allowed" : "denied";
  120. // erlaubt
  121. // Entferne die Erlaubnis für das Marketing, Newsletter veröffentlichen und
  122. // archivieren zu können
  123. $acl->removeAllow('marketing',
  124. 'newsletter',
  125. array('publish', 'archive'));
  126. echo $acl->isAllowed('marketing', 'newsletter', 'publish') ?
  127. "allowed" : "denied";
  128. // verweigert
  129. echo $acl->isAllowed('marketing', 'newsletter', 'archive') ?
  130. "allowed" : "denied";
  131. // verweigert
  132. ]]>
  133. </programlisting>
  134. <para>
  135. Rechte können schrittweise wie oben angezeigt verändert werden, aber ein
  136. <code>null</code> Wert für die Rechte überschreibt solche schrittweisen Änderungen:
  137. </para>
  138. <programlisting role="php"><![CDATA[
  139. // Erlaube dem Marketing alle Rechte für die neuesten Nachrichten
  140. $acl->allow('marketing', 'latest');
  141. echo $acl->isAllowed('marketing', 'latest', 'publish') ?
  142. "allowed" : "denied";
  143. // erlaubt
  144. echo $acl->isAllowed('marketing', 'latest', 'archive') ?
  145. "allowed" : "denied";
  146. // erlaubt
  147. echo $acl->isAllowed('marketing', 'latest', 'anything') ?
  148. "allowed" : "denied";
  149. // erlaubt
  150. ]]>
  151. </programlisting>
  152. </sect2>
  153. </sect1>
  154. <!--
  155. vim:se ts=4 sw=4 et:
  156. -->