Zend_Acl-Refining.xml 6.2 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193
  1. <sect1 id="zend.acl.refining">
  2. <title>Analiza kontroli dostępu</title>
  3. <sect2 id="zend.acl.refining.precise">
  4. <title>Precyzyjna kontrola dostępu</title>
  5. <para>
  6. Podstawowe ACL zdefiniowane w
  7. <link linkend="zend.acl.introduction">poprzedniej sekcji</link> pokazują
  8. jakie rozmaite uprawnienia mogą być dozwolone dla ACL (dla wszystkich
  9. zasobów). W praktyce, kontrola dostępu ma skłonność do posiadania
  10. wyjątków od reguł oraz różnych stopni skomplikowania. Zend_Acl pozwoli
  11. ci przeprowadzić te analizy w przystępny i elastyczny sposób.
  12. </para>
  13. <para>
  14. W przykładowej aplikacji CMS, zostało zdecydowane, że podczas gdy
  15. grupa 'staff' pokryje potrzeby większości użytkowników, potrzebna jest
  16. jeszcze jedna nowa grupa 'marketing', która wymaga dostępu do
  17. newslettera oraz ostatnich nowości w CMS. Ta grupa jest naprawdę
  18. samowystarczalna i będzie dawała możliwość publikowania oraz
  19. archiwizowania zarówno newsletterów jak i ostatnich nowości.
  20. </para>
  21. <para>
  22. Dodatkowo, zażądano także aby grupa 'staff' miała pozwolenie do
  23. przeglądania nowości, ale żeby nie mogła przeglądać ostatnich nowości.
  24. Dodatkowo, archiwizowanie 'zapowiedzi' nie powinno być w ogóle możliwe
  25. (nawet przez administratora), ponieważ ich okres ważności to 1-2 dni.
  26. </para>
  27. <para>
  28. Wpierw przejrzymy rejestr ról, aby rozważyć te zmiany. Określiliśmy, że
  29. grupa 'marketing' ma te same podstawowe uprawnienia co grupa 'staff',
  30. więc zdefiniujemy grupę 'marketing' w taki sposób, aby dziedziczyła
  31. uprawnienia od grupy 'staff':
  32. </para>
  33. <programlisting role="php"><![CDATA[
  34. // Nowa grupa marketing dziedziczy uprawnienia od grupy staff
  35. $acl->addRole(new Zend_Acl_Role('marketing'), 'staff');
  36. ]]>
  37. </programlisting>
  38. <para>
  39. Zauważ, że powyższa kontrola dostępu odnosi się do określonych zasobów
  40. (np., "newsletter", "ostatnie nowości", "zapowiedzi"). Teraz dodamy te
  41. zasoby:
  42. </para>
  43. <programlisting role="php"><![CDATA[
  44. // Utwórz zasoby dla reguł
  45. // newsletter
  46. $acl->add(new Zend_Acl_Resource('newsletter'));
  47. // nowości
  48. $acl->add(new Zend_Acl_Resource('news'));
  49. // ostatnie nowości
  50. $acl->add(new Zend_Acl_Resource('latest'), 'news');
  51. // zapowiedzi
  52. $acl->add(new Zend_Acl_Resource('announcement'), 'news');
  53. ]]>
  54. </programlisting>
  55. <para>
  56. Teraz prostą sprawą jest zdefiniowanie bardziej specyficznych reguł
  57. na docelowych obszarach ACL:
  58. </para>
  59. <programlisting role="php"><![CDATA[
  60. // Grupa marketing musi mieć możliwość publikowania i archiwizowania
  61. // newsletterów oraz ostatnich nowości
  62. $acl->allow('marketing',
  63. array('newsletter', 'latest'),
  64. array('publish', 'archive'));
  65. // Grupa Staff (oraz marketing przez dziedziczenie), ma zabroniony dostęp
  66. // do przeglądania ostatnich nowości
  67. $acl->deny('staff', 'latest', 'revise');
  68. // Każdy (włączając w to administratorów) ma zabroniony dostęp do
  69. // archiwizowania zapowiedzi
  70. $acl->deny(null, 'announcement', 'archive');]]>
  71. </programlisting>
  72. <para>
  73. Teraz możemy przeprowadzić zapytanie do ACL z uwzględnieniem ostatnich zmian:
  74. </para>
  75. <programlisting role="php"><![CDATA[
  76. echo $acl->isAllowed('staff', 'newsletter', 'publish') ?
  77. "allowed" : "denied";
  78. // zabronione
  79. echo $acl->isAllowed('marketing', 'newsletter', 'publish') ?
  80. "allowed" : "denied";
  81. // dozwolone
  82. echo $acl->isAllowed('staff', 'latest', 'publish') ?
  83. "allowed" : "denied";
  84. // zabronione
  85. echo $acl->isAllowed('marketing', 'latest', 'publish') ?
  86. "allowed" : "denied";
  87. // dozwolone
  88. echo $acl->isAllowed('marketing', 'latest', 'archive') ?
  89. "allowed" : "denied";
  90. // dozwolone
  91. echo $acl->isAllowed('marketing', 'latest', 'revise') ?
  92. "allowed" : "denied";
  93. // zabronione
  94. echo $acl->isAllowed('editor', 'announcement', 'archive') ?
  95. "allowed" : "denied";
  96. // zabronione
  97. echo $acl->isAllowed('administrator', 'announcement', 'archive') ?
  98. "allowed" : "denied";
  99. // zabronione
  100. ]]>
  101. </programlisting>
  102. </sect2>
  103. <sect2 id="zend.acl.refining.removing">
  104. <title>Usuwanie kontroli dostępu</title>
  105. <para>
  106. Aby usunąć jedną lub więcej reguł z ACL, po prostu użyj dostępnych metod
  107. <code>removeAllow()</code> lub <code>removeDeny()</code>. Podobnie jak
  108. w metodach <code>allow()</code> oraz <code>deny()</code>, możesz podać
  109. wartość <code>null</code> aby oznaczyć wszystkie role, wszystkie zasoby
  110. i/lub wszystkie przywileje:
  111. </para>
  112. <programlisting role="php"><![CDATA[
  113. // Usunięcie zabronienia możliwości przeglądania ostatnich nowości
  114. // przez grupę staff (oraz marketing, przez dziedziczenie)
  115. $acl->removeDeny('staff', 'latest', 'revise');
  116. echo $acl->isAllowed('marketing', 'latest', 'revise') ?
  117. "allowed" : "denied";
  118. // dozwolone
  119. // Usunięcie wszystkich pozwoleń publikowania i archiwizowania newsletterów
  120. // przez grupę marketing
  121. $acl->removeAllow('marketing', 'newsletter', array('publish', 'archive'));
  122. echo $acl->isAllowed('marketing', 'newsletter', 'publish') ?
  123. "allowed" : "denied";
  124. // zabronione
  125. echo $acl->isAllowed('marketing', 'newsletter', 'archive') ?
  126. "allowed" : "denied";
  127. // zabronione
  128. ]]>
  129. </programlisting>
  130. <para>
  131. Przywileje mogą być modyfikowane inkrementalnie jak pokazano wyżej, ale
  132. wartość <code>null</code> dla przywilejów nadpisuje te inkrementalne
  133. zmiany:
  134. </para>
  135. <programlisting role="php"><![CDATA[
  136. // Nadanie grupie marketing wszystkich uprawnień związanych z ostatnimi nowościami
  137. $acl->allow('marketing', 'latest');
  138. echo $acl->isAllowed('marketing', 'latest', 'publish') ?
  139. "allowed" : "denied";
  140. // dozwolone
  141. echo $acl->isAllowed('marketing', 'latest', 'archive') ?
  142. "allowed" : "denied";
  143. // dozwolone
  144. echo $acl->isAllowed('marketing', 'latest', 'anything') ?
  145. "allowed" : "denied";
  146. // dozwolone
  147. ]]>
  148. </programlisting>
  149. </sect2>
  150. </sect1>