## Please edit system and help pages ONLY in the master wiki! ## For more information, please see MoinMoin:MoinDev/Translation. ##master-page:HelpOnAccessControlLists ##master-date:2008-09-27 12:31:58 #acl -All:write Default #format wiki #language de #pragma section-numbers 2 = Access Control Lists = 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. == Inhalt == <> == Grundlagen == 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: {{{ #acl IrgendeinUser:read,write All:read }}} /!\ 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. <> == Konfiguration == Folgende Settings kann man benutzen, um ACLs zu konfigurieren: ||'''Setting'''||'''Default'''||'''Beschreibung'''|| ||acl_rights_before||{{{u""}}}||wird '''vor''' der Seiten- oder Default-ACL angewandt|| ||acl_rights_after||{{{u""}}}||wird '''nach''' der Seiten- oder Default-ACL angewandt|| ||acl_rights_default||{{{u"Trusted:read,write,delete,revert \}}}<
>{{{Known:read,write,delete,revert \}}}<
>{{{All:read,write"}}}||wird '''nur dann''' benutzt, wenn '''keine''' ACL auf der Seite angegeben wurde|| ||acl_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. == Syntax == Die Syntax jeder Zeile ist: {{{ #acl [+-]User[,SomeGroup,...]:[right[,right,...]] [[+-]OtherUser:...] [[+-]Trusted:...] [[+-]Known:...] [[+-]All:...] [Default] }}} Hier bedeutet: * '''User''' ist ein Benutzername und erteilt die zugehörige Berechtigung nur dann, wenn der Nutzername übereinstimmt. * '''Some``Group''' 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. == Mögliche Berechtigungen == Dies sind die verfügbaren Rechte, die in einer ACL benutzt werden können. Delete''''''Page und Rename''''''Page sind nicht erlaubt, wenn der Benutzer nicht `Known` ist, selbst wenn ein `delete`-Recht gewährt wurde. read:: Den angegebenen Benutzern wird Leserecht für diese Seite erteilt und sie dürfen auch Dateianhänge lesen/herunterladen. write:: Den angegebenen Benutzern wird Schreibrecht (und damit das Editieren) der Seite erlaubt. Sie dürfen auch Dateianhänge hochladen. delete:: Die angegebenen Benutzer dürfen die Seite und ihre Anhänge löschen. revert:: Die angegebenen Benutzer dürfen eine ältere Version der Seite restaurieren. admin:: Die 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. ##TODO: update stuff below: == Verarbeitungslogik auf einer einzelnen Seite == 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. {{{ #acl IrgendeinUser:read,write IrgendeineGruppe:read,write,admin All:read }}} 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: {{{ #acl -EinUser:admin EineGruppe:read,write,admin All:read }}} 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: {{{ #acl +All:read -EinUser:admin EineGruppe:read,write,admin }}} `+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. <> == Erben von Default-Einstellungen == 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: {{{ acl_rights_default = "TrustedGroup:read,write,delete,revert All:read" acl_rights_before = "AdminGroup:admin,read,write,delete,revert +TrustedGroup:admin" }}} 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:{{{ #acl EinUser:read,write Default }}} 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: {{{ #acl EinUser:read,write TrustedGroup:read,write,delete,revert All:read }}} 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. <> == Hierarchische ACL-Verarbeitung == {i} Neu in Version 1.6 Wenn Sie `acl_hierarchic` aktivieren (siehe [[#Konfiguration|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_after|| Beachten 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. <> == Gruppen == Benutzergruppen erleichtern es, Rechte für Gruppen von Personen zu spezifizieren. Nur die Freunde von `EinUser` dürfen diese Seite lesen und editieren: {{{ #acl EinUser:read,write EinUser/FreundesGruppe:read,write }}} `EinUser/FreundesGruppe` ist eine Seite, auf der jeder Listen-Eintrag einem Wiki-Usernamen entspricht, der zu genau dieser Gruppe gehören soll: {{{ #acl EinUser:read,write,admin,delete,revert * JoeSmith * JoeDoe * JoeMiller }}} Eine Seite `AdminGroup` könnte eine gleichnamige Gruppe definieren und ebenfalls durch ACLs geschützt werden: {{{ #acl AdminGroup:admin,read,write All:read * EinUser * EinWeitererUser * Dies wird momentan ignoriert. Auch jeder weitere Text, der nicht in der Liste der ersten Ebene steht, wird ignoriert. }}} /!\ 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: {{{ * ein benutzer -- zwei Leerzeichen, deshalb funktioniert dies nicht }}} Man kann konfigurieren, welche Seitennamen als Gruppenseiten betrachtet werden (z.B. für nicht-englische Wikis): {{{ page_group_regex = ur'(?P(?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). == Nutzungs-Beispiele == Siehen unten auf HelpOnAccessControlLists.