Zend_Acl-Advanced.xml 7.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114
  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <!-- Reviewed: no -->
  3. <sect1 id="zend.acl.advanced">
  4. <title>Расширенное использование</title>
  5. <sect2 id="zend.acl.advanced.storing">
  6. <title>Постоянное хранение данных ACL</title>
  7. <para>
  8. <classname>Zend_Acl</classname> спроектирован таким образом, что не требует для хранения
  9. данных <acronym>ACL</acronym> использования строго определенных технологий хранения -
  10. таких, как база данных или сервер кеша. Его реализация на чистом <acronym>PHP</acronym>
  11. позволяет создавать административные инструменты под управлением
  12. <classname>Zend_Acl</classname> с относительной простотой и гибкостью.
  13. Многие ситуации требуют некоторой интерактивной поддержки от <acronym>ACL</acronym>, и
  14. <classname>Zend_Acl</classname> предоставляет методы для настройки, произведения запросов,
  15. контроля доступа приложением.
  16. </para>
  17. <para>
  18. Тем не менее, хранение данных <acronym>ACL</acronym> остается задачей разработчика,
  19. т.к. случаи использования могут сильно варьироваться в различных
  20. ситуациях. Поскольку <classname>Zend_Acl</classname> доступен для сериализации, то можно
  21. сериализовать объекты <acronym>ACL</acronym> через PHP-функцию
  22. <ulink url="http://php.net/serialize"><code>serialize()</code></ulink>,
  23. и результаты можно хранить там, где пожелает разработчик - например,
  24. в файле, базе данных или с помощью механизма кэширования.
  25. </para>
  26. </sect2>
  27. <sect2 id="zend.acl.advanced.assertions">
  28. <title>Написание условных правил ACL с утверждениями</title>
  29. <para>
  30. Иногда правило разрешения или запрета доступа роли к ресурсу должно
  31. быть не безусловным, а зависеть от различных критериев. Например,
  32. определенный доступ должен быть разрешен, но только с 8:00 до 17:00.
  33. Другой пример - доступ должен быть запрещен, если запрос поступил
  34. с IP-адреса, находящегося в "черном списке". <classname>Zend_Acl</classname> имеет
  35. встроеную поддержку для применения правил, основанных на любых
  36. нужных разработчику условиях.
  37. </para>
  38. <para>
  39. <classname>Zend_Acl</classname> предоставляет поддержку условных правил с помощью
  40. интерфейса <classname>Zend_Acl_Assert_Interface</classname>.
  41. Чтобы использовать интерфейс утверждений, разработчик должен
  42. написать класс, который реализует метод <code>assert()</code>
  43. интерфейса:
  44. </para>
  45. <programlisting language="php"><![CDATA[
  46. class CleanIPAssertion implements Zend_Acl_Assert_Interface
  47. {
  48. public function assert(Zend_Acl $acl,
  49. Zend_Acl_Role_Interface $role = null,
  50. Zend_Acl_Resource_Interface $resource = null,
  51. $privilege = null)
  52. {
  53. return $this->_isCleanIP($_SERVER['REMOTE_ADDR']);
  54. }
  55. protected function _isCleanIP($ip)
  56. {
  57. // ...
  58. }
  59. }
  60. ]]></programlisting>
  61. <para>
  62. После объявления класса утверждения разработчик должен передавать
  63. экземпляр этого класса при определении условных правил. Правило,
  64. которое создается с утверждением, применяется
  65. только тогда, когда метод утверждения возвращает true.
  66. </para>
  67. <programlisting language="php"><![CDATA[
  68. $acl = new Zend_Acl();
  69. $acl->allow(null, null, null, new CleanIPAssertion());
  70. ]]></programlisting>
  71. <para>
  72. Код выше создает условное правило, разрешающее
  73. всем доступ ко всем привилегиям всех ресурсов, за исключением
  74. случаев, когда IP-адрес запрашивающего занесен в "черный список".
  75. Если запрос приходит с IP-адреса, который не определяется как
  76. "белый", то правило не применяется.
  77. Поскольку правило применяется ко всем ролям, всем ресурсам и всем
  78. привилегиям, то "черный" IP приведет к запрещению доступа.
  79. Тем не менее, это особый случай, и следует понимать, что во всех
  80. других случаях (например, когда для правила были указаны роль,
  81. ресурс, или привилегия), невыполнение утверждения приводит к тому,
  82. что правило не применяется, и для определения того, реазрешить ли
  83. доступ или запретить, могут использоваться другие правила.
  84. </para>
  85. <para>
  86. Методу <code>assert()</code> объекта утверждения передаются ACL,
  87. роль, ресурс и привилегия, к которым применяется запрос на
  88. авторизацию (например, <code>isAllowed()</code>). Это нужно для
  89. предоставления контекста классу утверждения и определения его
  90. условий там, где это нужно.
  91. </para>
  92. </sect2>
  93. </sect1>
  94. <!--
  95. vim:se ts=4 sw=4 et:
  96. -->