Mit Access Control Lists (kurz: ACLs, auf deutsch:Zugriffs-Kontroll-Listen) kann man bestimmten Benutzern oder Benutzergruppen das Recht geben, bestimmte Aktionen auszuführen. Sie können benutzt werden, um: einige Seiten vor der Öffentlichkeit zu verstecken nur bestimmte Seiten der Öffentlichkeit zugänglich zu machen einer Person oder einer Gruppe Schreibzugriff auf eine oder mehrere Seiten zu geben das Löschen von Seiten zu erlauben oder zu verbieten zu bestimmen, wer Zugriffsregeln einer Seite ändern darf Um ACLs zu benutzen brauchen Sie entweder Zugriff auf die Wiki-Config (um globale ACLs zu setzen) oder admin-Rechte auf der Seite, wo Sie ACLs setzen oder ändern wollen.

Die verfügbaren ACL-Rechte sind: read - wer darf eine Seite lesen write - wer darf eine Seite editieren delete - wer darf eine Seite löschen revert - wer darf eine alte Revision einer Seite restaurieren admin - wer darf die "#acl"-Zeile auf einer Seite ändern ACLs können in moin einfach durch Hinzufügen einer Steueranweisung am Anfang einer Seite realisiert werden: /!\ Sie benötigen admin-Rechte, um eine solche ACL-Zeile hinzufügen oder ändern zu können - siehe HelpOnConfiguration und HelpOnAutoAdmin. Das erlaubt IrgendeinUser, die Seite zu lesen und zu bearbeiten, während alle anderen Nutzer lediglich Lese-Rechte in der Seite haben (außer man hat einige Spezial-Konfigurationen in der Konfiguration gemacht). Dateianhänge werden ebenfalls durch die ACLs der Seite kontrolliert, an die sie angehängt sind.

Folgende Settings kann man benutzen, um ACLs zu konfigurieren: SettingDefaultBeschreibungacl_rights_beforeu""wird vor der Seiten- oder Default-ACL angewandtacl_rights_afteru""wird nach der Seiten- oder Default-ACL angewandtacl_rights_defaultu"Trusted:read,write,delete,revert \Known:read,write,delete,revert \All:read,write"wird nur dann benutzt, wenn keine ACL auf der Seite angegeben wurdeacl_rights_valid["read", "write", "delete", "revert", "admin"]Dies sind die gültigen (bekannten) Rechte.acl_hierarchic False Schaltet hierarchische ACL-Verarbeitung an, siehe #hierarchisch Nun wissen Sie, was es macht - aber was bedeutet es? "before" bedeutet Rechte erzwingen - benutzen Sie das für globale Admins oder Editoren "default" bedeutet was wird getan, wenn keine ACLs auf der Seite angegeben wurden. Es ist gleichbedeutend wie wenn man genau diese ACLs auf eine Seite schreibt. Außerdem sind dies die Rechte, die einbezogen werden, wenn Default in einer ACL auf einer Seite angegeben wird. "after" bedeutet, etwas nicht aus Versehen zu vergessen (wie z.B. jedem Leserechte zu geben) Es hilft, wennn Sie sich das einfach als "vor" (before), während, und "nach" (after) der Verarbeitung von seitenbasierten ACLs vorstellen. (!) Die u""-Notation, die für die Settings benutzt wird, bedeutet unicode und muss verwendet werden - siehe HelpOnConfiguration.

Die Syntax jeder Zeile ist: Hier bedeutet: User ist ein Benutzername und erteilt die zugehörige Berechtigung nur dann, wenn der Nutzername übereinstimmt. SomeGroup ist ein Seitenname, der auf page_group_regex passt, mit Zeilen der Form " * Member" (siehe #Gruppen). Trusted ist eine spezielle Gruppe, die alle authentifizierten Nutzer einer Trusted-Authentifizierungsmethode enthält. Known ist eine spezielle Gruppe, die alle angemeldeten Nutzer enthält. All ist eine allgemeine Gruppe, die alle Nutzer enthält, sowohl bekannte als auch anonyme. Default ist ein Eintrag, der in allen ACLs die Einträge von acl_rights_default ersetzt. (Siehe #Default). right ist eine "Berechtigung" der Art read, write, delete, revert, admin. Nur Wörter in acl_rights_valid werden akzeptiert, alle anderen werden ignoriert. Es ist durchaus zulässig, keine Rechte zu spezifizieren, was soviel bedeutet, dass keine Rechte gewährt werden.

Dies sind die verfügbaren Rechte, die in einer ACL benutzt werden können. DeletePage und RenamePage sind nicht erlaubt, wenn der Benutzer nicht Known ist, selbst wenn ein delete-Recht gewährt wurde. readDen angegebenen Benutzern wird Leserecht für diese Seite erteilt und sie dürfen auch Dateianhänge lesen/herunterladen. writeDen angegebenen Benutzern wird Schreibrecht (und damit das Editieren) der Seite erlaubt. Sie dürfen auch Dateianhänge hochladen. deleteDie angegebenen Benutzer dürfen die Seite und ihre Anhänge löschen. revertDie angegebenen Benutzer dürfen eine ältere Version der Seite restaurieren. adminDie angegebenen Benutzer haben Adminrechte auf dieser Seite. Das bedeutet, dass sie selbst ACL-Einstellungen ändern dürfen - inklusive dem Recht, andere zu "Admins" zu machen oder ihnen das "Admin"-Recht zu entziehen. /!\ Es gibt kein separates rename-Recht: eine Seite/Anhang umzubenennen setzt voraus, dass ein Benutzer "read"-, "write"- und "delete"-Rechte hat.

Wenn ein Benutzer versucht, eine ACL-geschütze Seite abzurufen, werden die ACLs der Reihenfolge nach abgearbeitet. Die erste "passende" ACL sagt aus, was der Benutzer mit der Seite tun (oder nicht tun) darf und die Verarbeitung hält an, sobald ein zum Benutzer passender ACL-Eintrag gefunden wurde. (!) Aufgrund dieses first match-Algorithmus sollte man die ACLs sortieren: Zu Beginn einzelne Usernamen, dann spezielle Gruppen, anschließend algemeinere Gruppen und zum Schluss Known und All. Beispielsweise sagt die folgende ACL aus, dass IrgendeinUser lesend und schreibend auf die ACL-geschützte Seite zugreifen darf, dass alle Mitglieder der Gruppe IrgendeineGruppe (ausser IrgendeinUser, falls er Mitglied der Gruppe ist) zusätzlich auch Admin-Rechte haben, während alle anderen User lediglich lesen dürfen. Um das ACL-System flexibler zu gestalten, gibt es zwei Präfixe '+' und '-'. Wenn sie benutzt werden, hält die Verarbeitung nur dann an, wenn das angeforderte Recht für einen bestimmten Benutzer mit dem Benutzer und Recht in dem gegebenen ACL-Eintrag übereinstimmt, läuft aber weiter, wenn nach einem anderen Recht (oder anderen Benutzer) gesucht wird. Im Fall von '+' wird das Recht gewährt, im Fall von '-' wird das Recht verweigert. Zum Beispiel kann die o.g. ACL auch folgendermaßen geschrieben werden, wenn EinUser Mitglied von EineGruppe ist: Dieses Beispiel ist nur für EinUser besonders, denn wenn admin-Rechte für EinUser abgefragt werden, wird es verweigert werden und die Verarbeitung hält an. In allen anderen Fällen, geht die Verarbeitung weiter. Oder auch: +All:read bedeutet, dass wenn irgendein Benutzer das read-Recht anfordert, es gewährt werden wird und die Verarbeitung anhält. In jedem anderen Fall, wird die Verarbeitung weiterlaufen. Wenn das admin-Recht für Benutzer EinUser abgefragt wird, wird es verweigert werden und die Verarbeitung hält an. In jedem anderen Fall, geht die Verarbeitung weiter. Letztendlich wird, wenn ein Mitglied der Gruppe EineGruppe ein Recht verlangt, es dann gewährt, wenn es hier angegeben ist und verweigert, wenn nicht. Alle anderen Benutzer haben keine Rechte, es sei denn, sie werden durch die Konfiguration gewährt. Bitte beachten Sie, dass Sie das 2. und 3. Beispiel wohl kaum auf einer Wikiseite verwenden wollen. Derartige ACLs sind aber in den Konfigurationseinträgen des Wikis sinnvoll.

Manchmal ist es nützlich, jemandem Rechte zu vergeben, ohne die Default-Berechtigungen zu beeinflussen. Nehmen wir als Beispiel an, Sie hätten folgende Einträge in ihrer Konfiguration: Sie möchten einige Seiten zum Schreiben für EinUser freigeben, aber gleichzeitig das Default-Verhalten bezüglich All und der TrustedGroup beibehalten. Sie können einfach den Default-Eintrag nutzen:Das fügt die Einträge von acl_rights_default exakt an der Stelle ein, wo der "Default"-Ausdruck steht. Sie haben also das gleiche geschrieben wie: Nun schauen wir mal das erste Beispiel dieses Abschnitts genauer an: acl_rights_before = "AdminGroup:admin,read,write,delete,revert +TrustedGroup:admin" ACLs werden in der Reihenfolge "before", dann "Seiten-ACLs/default" und dann "after" verarbeitet, von "links nach rechts". Es fängt also links in "before" an mit AdminGroup:... - dies trifft zu, wenn der Benutzer ein Mitglied der AdminGroup ist. Wenn es zutrifft, erhält der Benutzer diese Rechte (arwdr) und die ACL-Verarbeitung hält an. Wenn es nicht zutrifft, geht die ACL-Verarbeitung weiter mit +TrustedGroup:admin - dies trifft zu, wenn der Benutzer Mitglied der TrustedGroup ist. Wenn es zutrifft, bekommt der Benutzer die Rechte (a) und - jetzt kommt der Unterschied wegen dem Plus-Präfix - die ACL-Verarbeitung geht weiter! Wenn es also weitere zutreffende Einträge gibt für diesen Benutzer oder seine Gruppe oder Known: oder All:, wird der Benutzer auch diese Rechte erhalten. Wenn es nicht zutrifft, geht die ACL-Verarbeitung weiter - mit den Seiten-ACLs (wenn es ACLs auf der Seite gibt) oder mit den default-ACLs (wenn es keine ACLs auf der Seite gibt) und zuletzt dann mit den "after"-ACLs. Weil dies genau das gleiche ausdrückt, hat das Erben von Default-Einstellungen den Vorteil, dass alle Änderungen an Default-Einstellungen automatisch in alle ACLs übernommen werden, die mit der Default-Einstellung arbeiten.

{i} Neu in Version 1.6 Wenn Sie acl_hierarchic aktivieren (siehe oben), dann werden die Wikiseiten als Hierarchie verstanden und Berechtigungen, die auf übergeordneten Seiten gesetzt werden, können die Zugriffsrechte des Benutzers beeinflussen. Kurz gesagt: wenn eine Berechtigung nicht durch die aktuelle Seite definiert ist, werden die ACLs der Elternseite geprüft, dann davon die Eltern, usw. bi es keine Elternseite mehr gibt. Alle normalen ACL-Regeln werden beachtet, wie oben beschrieben, aber anstatt nur die ACL der aktuellen Seite zu prüfen, wird an die #acl-Zeile der Seite alle #acl-Zeilen aller übergeordneten Seiten in der Hierarchie angehängt, bis zur obersten Seite. Betrachten Sie folgendes Beispiel einer Seite namens A/B/C/D, das die Verarbeitung mit und ohne hierarchische ACLs gegenüberstellt: acl_hierarchic Verarbeitungs-Abfolge False acl_rights_before, A/B/C/D, [acl_rights_default], acl_rights_after True acl_rights_before, A/B/C/D, A/B/C, A/B, A, [acl_rights_default], acl_rights_afterBeachten Sie, dass acl_rights_before, acl_rights_default, und acl_rights_after nicht einmal pro Seite in der Hierarchie angewendet werden, sondern nur einmal insgesamt. Für die default-ACL bedeutet das, dass sie immer noch wie zuvor funktioniert, sie wird aber nicht angewandt, wenn die aktuelle Seite keine ACLs definiert, sondern nur wenn gar keine der Seiten in der Hierarchie eine ACL definieren. Im Endeffekt tun also hierarchische ACLs nichts anderes, als die ACL der aktuellen Seite durch eine Aneinanderreihung aller #acl-Zeilen, die in der Hierarchie dieser Seite gefunden werden, zu ersetzen.

Benutzergruppen erleichtern es, Rechte für Gruppen von Personen zu spezifizieren. Nur die Freunde von EinUser dürfen diese Seite lesen und editieren: EinUser/FreundesGruppe ist eine Seite, auf der jeder Listen-Eintrag einem Wiki-Usernamen entspricht, der zu genau dieser Gruppe gehören soll: Eine Seite AdminGroup könnte eine gleichnamige Gruppe definieren und ebenfalls durch ACLs geschützt werden: /!\ Eine Liste der ersten Ebene ist eine mit nur einem Leerzeichen vor dem Stern (und es muss auch ein Leerzeichen hinter dem Stern sein). Folgendes wird nicht funktionieren: Man kann konfigurieren, welche Seitennamen als Gruppenseiten betrachtet werden (z.B. für nicht-englische Wikis): (?P\S+)Group)' # dies ist der Default-Wert (nur Englisch)]]>/!\ Wenn Änderungen an einer Gruppenseite sich nicht auswirken, sollte man MoinMoin den Cache neu aufbauen lassen, indem man einfach alle Dateien im Verzeichnis path_to_your_wiki_instance/data/cache/wikidicts/ löscht. (!) Bitte beachten Sie, dass Sie nach dem Anlegen einiger Gruppenseiten dann diese Gruppen auch in ACLs auf Ihren Wiki-Seiten oder in Ihrer Wiki-Konfiguration verwenden möchten (oder dass sonst sich nichts ändern wird - moin hat keine vordefinierten Gruppen bzw. keine vordefinierten ACLs für bestimmte Gruppen).

Siehen unten auf HelpOnAccessControlLists.