DokuWiki ist – wie die meisten Wiki – in der Basiskonfiguration sehr offen. Jeder hat das Recht, Seiten zu erstellen, zu editieren oder zu löschen. Manchmal ist es trotzdem besser, den Zugriff zu manchen oder allen Seiten zu beschränken. An diesem Punkt kommen Access Control Lists (ACL) ins Spiel. Diese Seite soll einen Überblick darüber geben, wie ACLs im DokuWiki arbeiten und wie sie konfiguriert werden.

Um ACL im DokuWiki zu aktivieren, benötigen Sie zumindest ein Standard-ACL. Kopieren Sie einfach jeweils die Beispieldateien conf/acl.auth.php.dist und conf/users.auth.php.dist nach conf/acl.auth.php und conf/users.auth.php. Danach sollte die Anmeldeseite funktionieren. Wenn Sie die Meldung „No ACL setup yet! Denying access to everyone.“ erhalten, dann stellen Sie sicher, dass der Code am Anfang der Datei acl.auth.php die Datei acl.auth.php (steht so im Original) liest und nicht users.auth.php.

Sie benötigen darüber hinaus einige config Optionen. Betrachten wir ein Beispiel, das Sie in ihre local.php einfügen könnten, um die Standard Klartext-Authentifizierung bei der öffentlichen Registrierung zu aktivieren:

  $conf['useacl']       = 1;        // this enables the ACL feature
  $conf['superuser']    = '@admin'; // admin group is superuser

useacl aktiviert das ACL-Feature. Wenn es aktiviert wurde, erscheint ein Login-Feld am Ende jeder Wikiseite, und die Benutzer können sich registrieren. Die Option superuser gibt an, wer in der Lage ist, im DokuWiki alles zu machen (einschließlich neue ACL-Beschränkungen hinzuzufügen) - dies kann entweder ein einzelner Benutzer oder eine Gruppe sein (gekennzeichnet durch ein führendes @). Wenn Sie ein DokuWiki von Anfang an mit ACL unter Benutzung eines Browsers installieren, klicken Sie den „Login“-Button, folgen Sie dem Link „register“, und registrieren Sie wenigstens einen Benutzer. (Wenn Sie keinen Registrierungslink sehen, dann sind die Dateirechte von conf/users.auth.php oder conf/acl.auth.php nicht korrekt und deswegen können keine neuen Daten dorthin geschrieben werden.) Dann editieren Sie conf/users.auth.php und befördern Sie wenigstens einen „user“ zum „admin“. Ab sofort gibt es einen zusätzlichen „Admin“-Button wenn Sie als ein Benutzer angemeldet sind, der zur „admin“-Gruppe gehört.

An diesem Punkt kann eine zusätzliche Sicherheitsfunktion aktiviert werden. Um Benutzern zu verbieten, sich selbst zu registrieren fügen Sie 'register' zu den disableactions-Optionen hinzu:

  $conf['disableactions'] = 'register';        // users are no longer allowed to register themselves

Früher wurde dies mittels der openregister-Option gemacht. Dies ist veraltet.

Auf diese Art und Weise können Benutzer nur von einem Administrator hinzugefügt werden (entweder durch das Admin-Webinterface oder durch den direkten Eintrag in conf/users.auth.php ).

Darüber hinaus gibt es zusätzliche Konfigurationsoptionen, die Kontrolle über andere Aspekte der ACLs erlauben. Viele werden hierfür aber die Standardeinstellungen für ausreichend halten.

$conf['autopasswd']  = 1;                //autogenerate passwords and email them to user
$conf['passcrypt']   = 'smd5';           //Used crypt method (smd5,md5,sha1,ssha,crypt,mysql,my411)
$conf['defaultgroup']= 'user';           //Default groups new Users are added to
$conf['profileconfirm'] = '1';           //Require current password to confirm changes to user profile
$conf['authtype']     = 'plain';         // plaintext backend (default)

• Ändern Sie autopasswd auf 0 um dem Benutzer die Auswahl eines eigenen Passwortes zu erlauben. Dies hat allerdings den Nebeneffekt, dass man nicht mehr überprüfen kann, ob der Benutzer sich auch mit einer korrekten Emailadresse registriert.
• passcrypt legt die Verschlüsselungsmethode für das Passwort fest.
• defaultgroup erklärt sich von selbst: alle neuen Benutzer werden zunächst in diese Gruppe eingetragen.
• Setzen Sie profileconfirm auf 0 um einem angemeldeten Benutzer zu erlauben, sein Profil zu ändern (Name, Passwort und Emailadresse) ohne es mit dem derzeitigen Passwort bestätigen zu müssen.
• DokuWiki kann verschiedene Wege benutzen um auf Benutzer- und Gruppendaten zuzugreifen. Standardmäßig benutzt es sein eigenes plaintext Verfahren. Das Verfahren wird durch die authtype-Option gewählt. Siehe hierzu backends um die verfügbaren Optionen zu sehen.

…

Benutzer können hinzugefügt, gelöscht und bearbeitet werden mittels usermanager. Für Informationen wie Benutzer manuell hinzugefügt werden lesen sie die Beschreibung in der plain backend Dokumentation. Standardmäßig können sich Benutzer selbst registrieren.

Siehe dazu: FAQ: How to disable open user registration

Zugriffsbeschränkungen werden mit pages und namespaces verbunden. Es gibt fünf Zugriffsrechte: read, edit, create, upload und delete (lesen, editieren, anlegen, hochladen und löschen). Jedes höhere Zugriffsrecht enthält die darunter liegenden. Dabei ist read das unterste und delete das höchste Recht. Die Rechte create, upload und delete können nur namespaces zugewiesen werden.

Wenn DokuWiki prüft, welche Rechte es einem Benutzer geben soll, benutzt es alle Regeln, die mit dem Benutzernamen übereinstimmen oder der Gruppenrechte der Gruppe, in der sich der Benutzer befindet. Die Regel mit dem höchsten Recht wird benutzt. Die Rechte werden zuerst für die Seite geprüft. Danach werden alle übergeordneten namespaces geprueft, bis eine zutreffende Regel gefunden wurde.

Um eine beschränkende Regel hinzuzufuegen, wechseln Sie auf die Seite, die beschränkt werden soll und wechseln dann auf die Administrationsoberfläche durch drücken des Admin Button (Nur verfügbar für den superuser). Dort selektieren Sie Access Control List Management. Ihnen wird dann eine Tabelle wie die folgende gezeigt, die alle Beschränkungen der ausgewählten Seite zeigt.

Beschränkungen werden in die oberste Zeile der Tabelle eingetragen. Sie müssen einen Bereich auswählen. Dies kann entweder die gewählte Seite selbst oder einer der namespaces sein, in denen sich die Seite befindet ¹⁾. Sie müssen ausserdem auswählen, wem Sie den Zugriff erlauben (oder verbieten) wollen; dies kann eine Gruppe oder ein Benutzer sein. Zum Schluss müssen Sie noch die Rechte wählen, die Sie gewähren wollen. Wird nichts gewählt, wird der gewählte Benutzer oder die gewählte Gruppe von der Benutzung der Seite oder des namespaces ausgeschlossen.

Anm.: Das delete-Recht betrifft nur media Dateien. Seiten können gelöscht (und wieder hergestellt) werden von jedermann, der wenigstens edit-Rechte hat. Jemand der upload-Rechte aber keine delete-Rechte hat, kann existierende media Dateien nicht mehr überschreiben.

ALL. Jeder, selbst Benutzer, die nicht angemeldet sind, sind Mitglieder der Gruppe ALL. Sie können diese Gruppe benutzen, um den Zugriff für alle Benutzer zu beschränken (als Standardeinstellung) um dann die Rechte ausgewählter Benutzer zu erweitern. Im Bildschirmfoto oben ist z.B. niemand berechtigt etwas hochzuladen ausser den Mitgliedern der Gruppe UPLOAD.

user. Alle Benutzer, die sich selbst registriert haben, sind automatisch Mitglied der Gruppe USER. Benutzen Sie dies, um angemeldeten Benutzern Rechte zu geben. Der Name dieser Gruppe wird durch die Option defaultgroup festgelegt. Anders als die virtuelle Gruppe ALL, ist die Gruppe „user“ real. Zu ihr werden alle Benutzer automatisch hinzugefügt, wenn die einfache Benutzerauthentifizierung benutzt wird. Wenn Sie ein anderes Verfahren verwenden, müssen Sie die Gruppen benutzen, die dieses Verfahren benutzt.

Zugriffsbeschränkungen werden in der Datei conf/acl.auth.php gesichert. Sie sollte durch den Webserver geschrieben werden können, wenn Sie die ACL Admin-Oberfläche benutzen wollen. Es wird nicht empfohlen, diese Datei manuell zu editieren. Benutzen Sie die Admin-Oberfläche.

Leere Zeilen und Kommentare im Stile der Shell werden ignoriert. Jede Zeile enthält drei Felder, die durch Leerzeichen getrennt sind:

• Der Name der Ressource. Dies kann entweder ein Seitenname oder ein Namespace sein. Namespaces werden durch ein zusätzliches Sternchen gekennzeichnet (siehe Beispiel unten)
• Eine Gruppe oder Benutzername. Gruppennamen werden mit einem fuehrenden @ Zeichen gekennzeichnet.
• Ein Rechtelevel (siehe unten)

Es gibt 7 Rechtelevel, die durch eine Zahl repräsentiert werden. Höhere Levels beinhalten tiefere. Wenn Sie editieren können, dann können Sie auch lesen. Trotzdem sollte das admin-Recht von 255 nie in der conf/acl.auth.php Datei benutzt werden. Es wird nur intern bei der Prüfung der Übereinstimmung der superuser Option benutzt.

Hier ist ein Beispiel:

*                     @ALL        4
*                     bigboss    16
start                 @ALL        1
marketing:*           @marketing  8
devel:*               @ALL        0
devel:*               @devel      8
devel:*               bigboss    16
devel:funstuff        bigboss     0
devel:*               @marketing  1
devel:marketing       @marketing  2

Lassen Sie uns das Beispiel Zeile für Zeile durchsehen (s. unten für weitere Informationen):

1. Dies setzt Rechte fuer den Haupt-Namespace. Erlaubt jedem, Seiten zu editieren und anzulegen. Trotzdem ist upload nicht erlaubt.
2. Benutzer bigboss werden alle Rechte gegeben.
3. Die Rechte für die Startseite werden für jedermann auf nur-lesen gesetzt.
4. Dann werden die Rechte für den Namespace marketing gesetzt. Allen Mitgliedern der marketing Gruppe wird erlaubt, hier hochzuladen - fuer andere Benutzer gilt Zeile 1, die anlegen und editieren erlaubt. bigboss erbt seine Rechte von Zeile 2, so dass er hochladen und loeschen kann.
5. Der Zugriff auf den namespace devel wird beschraenkt. Niemand darf etwas machen.
6. na gut, nicht wirklich jeder – hier geben wir den Mitgliedern der Gruppe devel volle Rechte
7. und natuerlich darf bigboss alles – er darf sogar hochgeladene Dateien loeschen
8. die devel-Leute wollen aber nicht, dass ihr Boss die funstuff-Seite sieht – erinnern Sie sich: genaue Seitenrechte überschreiben namespace Rechte
9. und das marketing-Team darf auch alles im devel-Namespace lesen
10. und zum Schluss wird den marketing-Leuten erlaubt, die devel:marketing-Seite zu editieren.

Bitte beachten Sie, dass die Reihenfolge in der Datei egal ist. Die Datei wird als Ganzes analysiert und das Wiki sucht die perfekte Übereinstimmung für die Seiten/Benutzer-Kombinationen. Wenn eine Übereinstimmung gefunden wird, wird die Suche abgebrochen. Wenn keine Übereinstimmung gefunden wird, dann werden die Gruppenrechte der zu aktuellen Seite geprüft. Wird auch hier keine Übereinstimmung gefunden, wird die Prüfung mit dem nächsthöheren Namespace fortgesetzt.

Sie sehen im obigen Beispiel die Recht für die Benutzer bigboss. Ihm wurde via Zeile 2 der volle Zugriff gewährt, aber er benötigt den vollen Zugriff auf den devel:* namespace via Zeile 7 noch einmal. Wäre die Zeile nicht da, dann wäre die erste Übereinstimmung für den Benutzer bigboss und Seiten innerhalb des devel Namespace die Zeile 5, weil bigboss Mitglied der magischen Gruppe ALL ist.

Anm.: Um Benutzer und Gruppen mit speziellen Zeichen (wie Leerzeichen) zu konfigurieren müssen Sie den Namen „URL escapen“. Das trifft nur auf spezielle Zeichen im unteren 128 Byte Bereich zu. Die ACL Datei benutzt UTF-8 Codierung. Dadurch kann jedes Multibyte-Zeichen geschrieben werden, wie es ist. Dies trifft nur dann zu, wenn ein Verfahren benutzt wird, dass anders ist als plain – das einfache Verfahren erlaubt keine speziellen Zeichen.

Meldung „No ACL setup yet! Denying access to everyone.“ kann auch von einem fehlenden PHP Modul verursacht werden, natürlich nur wenn man die Authentifizierung über das Microsoft ActiveDirectory erledigt. php5-ldap