Zope - ein einfaches Content Management System

Übersicht: Content Management-Aspekte

• Undo
• History
• Unterstützung von Zusammenarbeit 
• Import und Export von Objekten
• Versionen
• Benutzer- und Sicherheitskonzept 
  
• Grundbegriffe
  
• Authentifizierung und Benutzerverwaltung
• Autorisierung und Sicherheitsverwaltung
• Datenbankzugriff
• Suchmaschine
• Skalierbarkeit

Dieses Kapitel behandelt die Aspekte, die für einen Einsatz von Zope als Content Management System unerlässlich sind. Dazu gehören allgemein die Möglichkeit, Fehler rückgängig zu machen, Revisionsverwaltung, eine effektive Unterstützung von Zusammenarbeit, ein ausgefeiltes Benutzer- und Sicherheitskonzept, Zugriff auf relationale Datenbanken, Suchmaschinenfunktionalität und Skalierbarkeit.

Undo - Fehler rückgängig machen

Jede Aktion in Zope, die eine Änderung von Objekten bewirkt, kann über den Undo-Reiter rückgängig gemacht werden. Dadurch kann der Status vor einem gemachten Fehler wiederhergestellt werden, wie z.B. ein versehentlich gelöschter Ordner durch Widerrufen der Delete-Aktion. Die Undo-Funktionalität wird über den Undo-Reiter gesteuert:
 

Abb. 10: Die Undo-Ansicht

Die Auswahl der ersten Transaktion /manage_delObjects und ein Klick auf "Undo" widerruft die letzte Transaktion und stellt somit den Ordner wieder her. Undo arbeitet auf der ZODB, wobei Änderungen daran in Transaktionen vor sich gehen. In Zope ist eine Transaktion als jede Änderung vorstellbar, die bei einer Aktion eintritt (z.B. Erstellung eines Ordners, Einfügen von Objekten an einer neuen Stelle). Allerdings kann eine Transaktion, von der eine spätere Transaktion abhängt, nicht widerrufen werden: Wird ein Objekt in einen Ordner eingefügt und dann ein Objekt in demselben Ordner gelöscht, soll z.B. das vorherige Einfügen widerrufen werden. Die Lösung ist, einfach beide Transaktionen zu widerrufen. Ein anderes Problem ist, dass ein Undo nicht rückgängig gemacht werden kann. Deshalb kann ein neuer Ordner nach Widerruf dieser Aktion nicht durch Rückgängig machen des Undos zurückerhalten werden. Nur Änderungen an in Zope gespeicherten Objekten können rückgängig gemacht werden, nicht jedoch integrierte Daten in einem relationalen Datenbankserver wie Oracle oder MySQL.

History - Änderungen an Dokumenten verfolgen

Oft ist es nützlich, nur die Änderung an einem Objekt zu widerrufen. Wurde z.B. ein Dokument in einer Transaktion bearbeitet, die auch das Verschieben beinhaltete, soll z.B. zwar die Änderung am Dokument, nicht aber das Verschieben der Datei widerrufen werden. Dazu kann die History-Ansicht mit den vorherigen Zuständen eines Objekts verwendet werden: 


Abb. 11: Die History-Ansicht

DTML-Methoden und -Dokumente unterstützen sogar den Revisionsvergleich, um z.B. die aktuellste "neue" Version der Datei mit einer älteren zu vergleichen. Dieser Vergleich wird im weitverbreiteten Format namens diff angezeigt.

Unterstützung von Zusammenarbeit

Um dieses Problem zu beheben, hat Zope Versions-Objekte zum Vornehmen nicht-öffentlicher Änderungen. Zum Beispiel kann es eine Woche dauern, ein neues Menüsystem fertig zu stellen. Danach können alle Änderungen auf einmal durch Freigabe der Version veröffentlicht werden. Durch Klick auf eine Version wird sie verwendet: Dies öffnet die Ansicht "Join/Leave":


Abb. 12: Anmelden an einer Version

Die Arbeit an dieser 

" wird alles in den Zustand vor Verlassen der Version zurückversetzt. In der Ansicht "Save/Discard" können Änderungen dauerhaft gemacht werden:
 

Abb. 13: Versionsänderungen freigeben

Mit "Save" werden Änderungen öffentlich gemacht und alle in der Version geänderten Objekte sind jetzt nicht mehr gesperrt. Anschließend muss noch die Arbeit in der Version beendet werden (Ansicht Join/Leave). Nun sollte das in der Version erstellte Dokument und die Änderung am standard_html_header sichtbar sein. Auch Änderungen an Versionen können rückgängig gemacht werden, allerdings werden bei Widerruf der Transaktion alle in der Version vorgenommenen Änderungen rückgängig gemacht.

Als Web-Applikation und im Besonderen als Content Management System ist es erforderlich, dass Zope Sicherheitsaspekten Rechnung trägt. Dies bedeutet z.B., zu kontrollieren, wer Zugang zu einer Applikation hat und festzulegen, was derjenige dort tun kann. In der Regel sollte Sicherheit ein wichtiges Design-Element in der Konzeptionsphase sein.

Grundbegriffe

Authentifizierung: bedeutet, herauszufinden, wer der Nutzer ist. Der Authentifizierungsprozess wird beim Aufruf einer geschützten Ressource (wenn z.B. eine private Website angesehen wird) ausgelöst, woraufhin zum Login aufgefordert und nach einem Benutzer-Account gesucht wird. Dies kann auch geschehen, wenn der Benutzer bereits eingeloggt ist. Werden nur öffentliche Ressourcen aufgerufen, wird Anonymität des Nutzers angenommen.
Autorisierung: bedeutet, festzulegen, was der Nutzer tun kann bzw. darf. Nach erfolgter Authentifizierung stellt Zope fest, ob Zugang zu der geschützten Ressource besteht oder nicht. Dieser
Prozess bezieht zwei vermittelnde Schichten zwischen dem Nutzer und der geschützten Ressource ein, nämlich Rollen und Erlaubnisse (roles und permissions).
Rollen: Benutzer haben Rollen, die beschreiben, was sie tun dürfen, wie etwa "Autor", "Manager" oder "Redakteur", aber auch "Anonymous" und "Authenticated". Sie bilden somit Klassen von Benutzern. Wie in UNIX-Gruppen werden Gruppen von Benutzern abstrahiert, und Zope-Benutzer können mehr als eine Rolle haben. Zope hat vier eingebaute Rollen:

Tab. 5: Rollen in Zope

Erlaubnisse: Erlaubnisse definieren, welche Aktionen mit Zope-Objekten durchgeführt werden können, wie etwa "Ansehen", "Objekte löschen" oder "Eigenschaften verwalten".
Sicherheitsregeln: Sicherheitsregeln teilen Rollen Erlaubnisse zu und autorisieren somit Benutzer, geschützte Aktionen durchzuführen. Sie legen fest, wer was tun darf. Zum Beispiel mag eine Sicherheitsregel die "Manager"-Rolle mit der Erlaubnis "Objekte löschen" assoziieren.

Authentifizierung und Benutzerverwaltung

Für ein Login unter Zope muss ein Benutzer-Account vorliegen. Ein Zope-Benutzer hat einen Namen, ein Passwort und optionale Daten. In Zope können beliebig viele Managerkonten und andere, eigene Arten von Benutzern, die bestimmten Gruppen angehören. Um Benutzer-Accounts anzulegen, werden Benutzer zu Benutzer-Verzeichnissen hinzugefügt (im Ordner acl_users):


Abb. 14: Hinzufügen eines Benutzers zu einem Benutzer-Ordner

Das Feld Domains erlaubt die Einschränkung von Internet-Domains, von denen aus sich der Benutzer einloggen kann (z.B. "myjob.com myhome.net", oder auch IP-Adressen). Als Rolle wird für Verwaltungsaufgaben i.d.R. Manager gewählt, die "Owner"-Rolle passt meist nicht, weil ein Benutzer der Eigentümer bestimmter Objekte ist, nicht ein Eigentümer im Allgemeinen.
Zope kann mehrere Benutzer-Ordner an verschiedenen Stellen der Objekthierarchie enthalten. Ein Zope-Benutzer hat ausschließlich Zugang zu Ressourcen in dem Benutzer-Ordner, in dem er definiert ist. Benutzer können in jedem Zope-Ordner definiert werden. Ein verbreitetes Zope-Verwaltungsmuster ist die Delegation, d.h. verwandte Objekte in einem Ordner und dann dort in einem Benutzer-Ordner verantwortliche Personen zu definieren. Manchmal soll der Benutzer-Account nicht durch das Web verwaltet werden, wenn z.B. schon eine Benutzerdatenbank vorliegt. Mit wechselnden Benutzer-Ordnern können alle Arten von Authentifikationstechniken benutzt werden. Die wichtigsten sind: LoginManager (erlaubt die Einbindung eigener Autorisierungsmethoden, z.B. um sich aus einer Datenbank heraus zu authentifizieren), etcUserFolder (authentifiziert über Standard-UNIX /etc/password style files),  LDAPAdapter (authentifiziert über einen LDAP-Server) und NTUserFolder (authentifiziert aus NT-Benutzer-Accounts heraus, funktioniert nur unter Windows NT oder Windows 2000).
Drei besondere Benutzer-Accounts werden nicht in Benutzer-Ordnern definiert: Anonymer Zope-Benutzer (Eingebauter Benutzer-Account für Gäste, die keinen Benutzer-Account haben, nur Zugriff auf öffentliche Ressourcen),  Notfall-Benutzer (Zweck: Reparieren durcheinandergebrachter Berechtigungen, z.B. bei versehentlichem Aussperren aus Zope) und Ursprungs-Manager (wird vom Zope-Installer zum Ermöglichen eines ersten Logins angelegt).

Autorisierung und Sicherheitsverwaltung

Zope-Sicherheitsregeln definieren, welche Rollen welche Erlaubnisse in einem bestimmten Teil der Site haben und kontrollieren somit die Autorisierung. Anstatt zu definieren, was jeder einzelne Benutzer tun kann, können einfach ein paar verschiedene Sicherheitsregeln für verschiedene Benutzerrollen festgelegt werden. Von den vorgestellten vier Standardrollen reichen für einfache Zope-Sites Manager und Anonym, für komplexere Sites empfiehlt sich das Anlegen eigener Rollen.
Rollen definieren: Neue Rollen werden in der Registerkarte "Security" im Feld "User defined role" festgelegt und können auf der Ebene der Definition benutzt werden und in der Objekthierarchie darunter. Im Allgemeinen sollten Rollen für große Abschnitte einer Site anwendbar sein. Anstatt neue Rollen anzulegen, ist es oft besser, Sicherheitseinstellungen vorhandener Rollen zu ändern oder Benutzer tiefer in der Objekthierarchie zu definieren, um ihren Zugang zu beschränken. Es gibt lokale Rollen, die einem bestimmten Benutzer besonderen Zugang zu einem Objekt gewähren (z.B. über die lokale Besitzerrolle). Im Regelfall sind jedoch Sicherheitseinstellungen für einzelne Benutzer zu vermeiden.
Über die Registerkarte Security ist z.B. auch einzusehen, dass ein Mail Host im Gegensatz zu Ordnern über eine recht eingeschränkte Erlaubnispalette verfügt:

Abb. 15: Sicherheitseinstellungen für ein Mail Host Objekt

Sicherheitsregeln definieren: Sicherheitsregeln legen fest, wer was in einem bestimmten Teil der Site tun kann. Das Kästchens an der Kreuzung zwischen einer Berechtigung und einer Rolle ordnet dem Benutzer mit dieser Rolle diese Berechtigung zu. Diese Regeln können durch Änderung der Sicherheitseinstellungen im Root-Ordner angepasst werden. Soll eine Site "privatisiert" werden, muss im entsprechenden Ordner allen anonymen Benutzern der "View"-Zugang verweigert werden. Im Root-Ordner bewirkt dies die Privatisierung einer gesamten Site.
Erwerben von Sicherheitsregeln: Objekte benutzen ihre eigenen Regeln, falls definiert, und erwerben die Sicherheitsregeln ihrer Haupt-Dokumente. Das Erwerben von Sicherheitsregeln wird in der Registerkarte Security über "Acquire permission settings" kontrolliert. Im Root-Ordner (ohne übergeordnetes Hauptdokument) gibt es die äußerste, linke Spalte nicht. Wenn irgend möglich, sollten Sicherheitseinstellungen übernommen werden.
Delegation von Kontrolle an lokale Manager: Dieses zentrale Sicherheitsmuster sieht vor, etwa Ressourcen in Ordnern zusammenzufassen und dann Benutzer-Accounts in diesen Ordnern anzulegen, um den Inhalt zu verwalten. Angenommen, die Verwaltung des Ordners Verkauf soll der neue Web-Verkaufsmanager Stefan übernehmen. Um zu verhindern, dass Stefan Änderungen außerhalb des Ordners Verkauf vornimmt, wird ein neuer Benutzer-Ordner direkt im Ordner Verkauf angelegt. Nun kann z.B. ein weiterer Benutzer 'Steve' mit der Managerrolle hinzugefügt werden. Stefan kann sich nun direkt im Ordner Verkauf einloggen, um seinen Bereich zu verwalten, indem er mit seinem Browser http://www.zopezoo.org/Verkauf/manage aufruft:
 

Abb. 16: Verwaltung des Ordners "Verkauf"

Der lokale Manager 'Steve' kann sich nun ausschließlich im Ordner Verkauf einloggen, der im Navigationsbaum auf der linken Seite als Root-Ordner angezeigt wird. Dieses Muster kann rekursiv angewandt werden: Stefan kann beispielsweise einen Unterordner für Multi-Level-Marketing-Verkäufe anlegen und dort Kontrolle weiter an Multi-Level-Marketing-Manager delegieren.

Sich häufende Anfragen können einen Server dermaßen überlasten, dass sie zu inakzeptablen Antwortzeiten und u.U. sogar zu Abstürzen führen. Diesem Problem kann durch Einsatz mehrerer Rechner mit identischen Serverkonfigurationen begegnet werden, so dass bei Ausfall eines Rechners andere Rechner im Verbund seine Aufgabe übernehmen können. Bedingung ist, dass auf allen Zope- Instanzen die gleichen Informationen vorliegen, was insbesondere auf großen Zope-Servern mit Tausenden sich stetig ändernden Objekten kaum mehr manuell zu bewältigen ist.
Das ZEO-System ermöglicht den Betrieb einer Website auf mehreren Rechnern, auch "Cluster" genannt. Mit einer solchen Anordnung können mittels Lastverteilungskomponente bei stark ansteigender Anfragelast die Anfragen auf mehrere Rechner verteilt werden. Ausserdem können im Falle eines Serverausfalles die noch intakten Rechner die Anfragen bedienen. Mit einem derartigem Serveraufbau kann ein defekter Rechner ausgetauscht oder repariert werden, ohne das von aussen ein Serverausfall spürbar wird.
Mit ZEO kann Zope auf mehreren Rechnern betrieben werden. ZEO garantiert, dass alle beteiligten Zope-Installationen jederzeit auf genau die selbe Datenbank zugreifen. ZEO benutzt dazu eine Client/Server-Architektur. Alle Clients verbinden sich mit einer zentralen Instanz, dem ZEO Speicher Server, so wie auch in Abb. 17 zu sehen ist:


Abb. 17: ZEO-Funktionsweise

Bei Einsatz von ZEO übernimmt Zope zugleich Server- (für die Beantwortung von Webanfragen) sowie Klientfunktionalität (um Daten vom ZEO-Server zu erhalten). ZEO Clients und Server kommunizieren über ein standardisiertes Internetprotokoll. Auf diese Art und Weise ist es möglich, beide im selben Raum oder aber auch in einem anderem Land zu betreiben.
Folgende Argumente sprechen für den Einsatz von ZEO:

• Eine Webseite kann Anfragen nicht mehr zügig beantworten
• Die Website erfordert eine 24/7-Verfügbarkeit => In diesem Falle erlaubt ZEO den Einsatz mehrerer sofortiger einsatzfähiger Ersatzserver
• Eine Website soll global über mehrere Mirror-Sites angeboten werden und an jedem Standort dieselben Daten per ZEO-Client zugreifen und schreiben können
• Ein ZEO-Client soll nach Fehlern untersucht (debuggen) werden, während die anderen Zeo-Clients weiterhin Webseiten ausliefern