2
0

Zend_Acl-Advanced.xml 5.2 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111
  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <!-- EN-Revision: 15814 -->
  3. <!-- Reviewed: no -->
  4. <sect1 id="zend.acl.advanced">
  5. <title>Fortgeschrittene Verwendung</title>
  6. <sect2 id="zend.acl.advanced.storing">
  7. <title>Dauerhafte Speicherung von ACL Daten</title>
  8. <para>
  9. <classname>Zend_Acl</classname> wurde so entwickelt, dass keine spezielle Backend
  10. Technologie benötigt wird, wie z.B. eine Datenbank oder ein Cache Server, um die
  11. <acronym>ACL</acronym> Daten zu speichern. Die vollständige <acronym>PHP</acronym>
  12. Implementation ermöglicht angepasste Administrationstools, die relativ einfach und
  13. flexibel auf <classname>Zend_Acl</classname> aufbauen. Viele Situationen erfordern eine
  14. interaktive Wartung der <acronym>ACL</acronym> und <classname>Zend_Acl</classname>
  15. stellt Methoden für das Einrichten und Abfragen der Zugriffskontrolle einer Anwendung.
  16. </para>
  17. <para>
  18. Die Speicherung der <acronym>ACL</acronym> Daten ist deshalb die Aufgabe des
  19. Entwicklers, da sich die Anwendungsfälle für verschiedene Situationen erwartungsgemäß
  20. stark unterscheiden. Da <classname>Zend_Acl</classname> serialisierbar ist, können
  21. <acronym>ACL</acronym> Objekte mit der <acronym>PHP</acronym> Funktion <ulink
  22. url="http://php.net/serialize"><methodname>serialize()</methodname></ulink>
  23. serialisiert werden und das Ergebnis kann überall gespeichert werden, wo es der
  24. Entwickler möchte, wie z.B. eine Datei, eine Datenbank oder ein Cache Mechanismus.
  25. </para>
  26. </sect2>
  27. <sect2 id="zend.acl.advanced.assertions">
  28. <title>Schreiben von bedingten ACL Regeln mit Behauptungen</title>
  29. <para>
  30. Manchmal soll eine Regel für das Erlauben oder Verbieten des Zugriffs auf eine
  31. Ressource nicht absolut sein, sondern von verschiedenen Kriterien abhängen. Zum
  32. Beispiel, nehmen wir an, dass ein bestimmter Zugriff erlaubt sei, aber nur zwischen
  33. 08:00 und 17:00 Uhr. Ein anderes Beispiel könnte sein, dass der Zugriff verboten wird,
  34. weil eine Anfrage von einer bestimmten IP Addresse kommt, die als Missbrauchsquelle
  35. markiert worden ist. <classname>Zend_Acl</classname> bietet eine eingebaute
  36. Unterstützung für die Implementierung von Regeln, die auf Bedingungen basieren, die der
  37. Entwickler benötigt.
  38. </para>
  39. <para>
  40. <classname>Zend_Acl</classname> bietet Unterstützung für bedingte Regel mit dem
  41. <classname>Zend_Acl_Assert_Interface</classname>. Um das Regelbehauptungsinterface
  42. benutzen zu können, schreibt der Entwickler eine Klasse, welche die
  43. <methodname>assert()</methodname> Methode des Interfaces implementiert:
  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. Sobald eine Behauptungsklasse verfügbar ist, muss der Entwickler eine Instanz dieser
  63. Aussageklasse bei der Zuordnung bedingte Regeln übergeben. Eine Regel, die mit einer
  64. Behauptung angelegt wird, wird nur angewendet, wenn die Behauptungsmethode
  65. <constant>TRUE</constant> zurück gibt.
  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. Der obige Code legt eine bedingte Erlaubnisregel an, die den Zugriff für alle Rechte
  73. auf alles und von jedem erlaubt, außer wenn die anfordernde IP auf einer "Blacklist"
  74. ist. Wenn die Anfrage von einer IP kommt, die nicht als "sauber" betrachtet wird, wird
  75. die Erlaubnisregel nicht angewandt. Da die Regel auf alle Rollen, alle Ressourcen und
  76. alle Rechte zutrifft, würde eine "unsaubere" IP zu einem Zugriffsverbot führen. Dies
  77. ist ein besonderer Fall und es sollte verstanden werden, dass in allen anderen Fällen
  78. (d.h. wenn eine spezielle Rolle, Ressource oder Recht für die Regel spezifiziert wird)
  79. eine fehlerhafte Behauptung dazu führt, dass die Regel nicht angewandt wird und andere
  80. Regeln verwendet werden, um zu ermittel, ob der Zugriff erlaubt oder verboten ist.
  81. </para>
  82. <para>
  83. Der <methodname>assert()</methodname> Methode eines Behauptungsobjektes werden die
  84. <acronym>ACL</acronym>, Rolle, Ressource and die Rechte übergeben, auf welche die
  85. Autorisierungsabfrage (d.h., <methodname>isAllowed()</methodname>) passt, um den
  86. Kontext für die Behauptungsklasse bereit zu stellen, um die Bedingungen zu ermitteln wo
  87. erforderlich.
  88. </para>
  89. </sect2>
  90. </sect1>
  91. <!--
  92. vim:se ts=4 sw=4 et:
  93. -->