Zend_Acl-Advanced.xml 5.0 KB

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