Bestimmten Benutzern das Editieren von Artikeln im MediaWiki erlauben

Es widerspricht zwar dem Wiki-Konzept, einzelnen Benutzern oder Benutzergruppen den Zugriff auf bestimmte Seiten zu verwehren bzw. zu erlauben, aber gerade in Unternehmen wird diese Anforderung doch recht schnell gestellt.

Nachdem ich einige Zeit die Mediawiki-Dokumentation durchforstet habe, bin ich zwar auf einige interessante Artikel zum Thema Einschränkung der Benutzerrechte gestoßen, aber meine Anforderungen konnte ich damit nicht abbilden:

  • Es soll zwei Benutzergruppen geben: “EDV” und “normale” Benutzer.
  • Die EDV-Benutzer sollen alles machen können (Seiten lesen, editieren etc.).
  • Die normalen Benutzer sollen nur die von mir definierten Seiten lesen bzw. bearbeiten können.
  • Anonyme Benutzer sollen gar nichts machen können (außer sich anzumelden).

Meine Lösung sieht nun folgendermaßen aus:

  • In der LocalSettings.php habe ich die Benutzerrechte der normalen Benutzer komplett deaktiviert (wobei für ‘*’ alle Rechte einzeln (siehe Liste) eingetragen werden müssen): $wgGroupPermissions['user']['*'] = false;
  • Der Benutzergruppe “EDV” werden hingegen analog die Rechte erteilt: $wgGroupPermissions['edv']['*'] = true;
  • Dann werden alle gewünschten Benutzer der Gruppe EDV zugeteilt (als “bureaucrat” unter Spezialseiten – Benutzerrechtsverwaltung).

Jetzt haben wir erreicht, dass nur Benutzer der Gruppe EDV die Seiten lesen und schreiben, aber alle anderen Benutzer gar nichts machen können. Jetzt müssen wir zunächst einige Seiten freischalten, die auch die normalen Benutzer sehen können (z.B. die Hauptseite und vor allem die Login-Seite). Dies geschieht auch wieder in der LocalSettings.php und zwar wie folgt: $wgWhitelistRead = array("Spezial:Userlogin"); Das Array enthält die Namen der Seiten, die von allen Benutzern (und auch anonymen Benutzern) eingesehen werden dürfen. Hierbei ist darauf zu achten, die Seitentitel korrekt formatiert einzutragen. Wir haben z.B. viele Artikel mit Umlauten und Sonderzeichen im Namen. Diese müssen mit Hilfe der Funktion urldecode() eingetragen werden: $wgWhitelistRead = array(urldecode("Pr%C3%BCfung der Werte %28KB%29")); Das Beispiel trägt den Artikel Prüfung der Werte (KB) in die Liste ein. Der korrekte Titel kann am einfachsten aus der Adresszeile des Browsers kopiert werden, nachdem der Artikel aufgerufen wurde. Einfach den Teil hinter “?title=” kopieren und die Unterstriche durch Leerzeichen ersetzen.

Lesen können unsere normalen Benutzer jetzt schon, aber editieren? Ich hatte zunächst an die Variable $wgWhitelistEdit gedacht, aber damit klappt es nicht. Daher habe ich folgende kleine Eigenentwicklung vorgenommen:

  • Ein Array in der LocalSettings.php anlegen, das frei benennbar ist (ich habe es $wgPagesAllUsersCanEdit genannt) und die gewünschten Seiten analog zu $wgWhitelistRead enthält.
  • In der Datei includes/User.php die Funktion isAllowed() suchen.
  • Sie dürfte wie folgt aussehen (MediaWiki v1.5.5): function isAllowed($action='') { $this->loadFromDatabase(); return in_array( $action , $this->mRights ); }
  • Diese Funktion wird nun wie folgt ersetzt: function isAllowed($action='') { $this->loadFromDatabase(); if (($action == 'edit') && $this->isLoggedIn()) { global $wgTitle, $wgPagesAllUsersCanEdit; $allowed_page_name = $wgTitle->getPrefixedText(); if( $wgPagesAllUsersCanEdit && in_array( $allowed_page_name, $wgPagesAllUsersCanEdit ) ) { return true; } } return in_array( $action , $this->mRights ); }

Somit wird nun jedes Mal beim Bearbeiten einer Seite abgefragt, ob der User angemeldet und die Seite von jedem Benutzer änderbar ist. Die EDV-Benutzer dürfen ja eh alles ändern, also gibt es für sie keine Einschränkungen.

Zuletzt muss noch sichergestellt werden, dass die Seiten in der Whitelist nicht von anonymen Benutzern gelesen und geändert werden können. Dies habe ich durch eine Erweiterung der schon vorhandenen Abfrage in index.php gelöst (Zeile 105 für MediaWiki v1.5.5).

Vorher: if ( !is_null( $wgTitle ) && !$wgTitle->userCanRead() )

Nachher: if ( ( !is_null( $wgTitle ) && ( $wgTitle->getPrefixedText() != "Spezial:Userlogin" ) ) && ( !$wgTitle->userCanRead() || $wgUser->isAnon() ))

UPDATE (MediaWiki v1.6.5): Bei der neuen Version habe ich die vorangehende Abfrage durch folgenden Code in Datei includes/Title.php in der Funktion userCanRead() ersetzt. Er wird vor der Abfrage if( $wgUser->isAllowed(‘read’) ) eingefügt. if( $wgUser->isAnon() && ("Spezial:Userlogin" != $this->getPrefixedText()) ) { return false; }

Das war’s! Jetzt sind meine Anforderungen abgedeckt und ich kann durch ein Ändern des selbst definierten Arrays den Benutzern einzelne Seiten zur Verfügung stellen (WICHTIG: Die Seiten müssen auch in der Read-Whitelist stehen, sonst werden sie nicht angezeigt!).

Über Stefan

Polyglot Clean Code Developer

7 Kommentare

  1. Hey,

    bin nicht der wiki-Experte, aber mit dokuwiki baue ich gerade ein wiki für die Abteilung auf, in der ich arbeite.
    Und ich muss sagen, ich bin echt begeistert. Installation geht ratz-fatz, man benötigt keine Datenbank (File-Storage) und vor allem gibt es einen eingebauten ACL Modus.

  2. Jupp, das DokuWiki kenne ich auch: einfach aber umfangreich. Aber im Vergleich mit MediaWiki schneidet es nicht so gut ab. Ich finde gerade die Plain-Text-Speicherung nicht vorteilhaft bei umfangreichen Datenbeständen.
    Aber wenn ihr auch ein Wiki im Unternehmen einsetzt, dann beteilige dich doch an der Umfrage von Wikipedistik, wenn du sie noch nicht kennst 🙂

  3. Die Umfrage kannte ich noch nicht.
    Wie jemand schon geschrieben, verwendet man Datenbank ja eher bei strukturierten Daten und bei wikis fallen ja eher unstrukturierte Daten an.
    Der klarer Vorteil liegt in der Suche von Einträgen, da die Suche im Dateisystem doch recht zeitaufwendig werden kann.
    Dafür könnte man im Zweifel aber beagle oder Lucene verwenden.
    Und wenn das wiki eh öffentlich im Internet steht, könnte man dafür auch Google benutzen. Spart Zeit und Rechenleistung.

  4. Diese WikiMatrix ist ja sau-cool

  5. Ich gebe zu, dass das Speichern in Textfiles auch Vorteile hat. Aber bei uns war die schnelle Suche ausschlaggebend für den Erfolg des Wikis. Und online ist das Wiki nicht, also können wir auch die Google-Suche nicht benutzen. Ok, Lucene wäre wirklich eine Alternative… aber egal. Inzwischen haben wir MediaWiki schon ausreichend erweitert, um unsere Anforderungen abzudecken.
    Aber ich muss sagen, dass sich das Dokuwiki stark weiterentwickelt hat. Als ich das letzte Mal in die Matrix (die wirklich sehr nett ist ;)) geschaut habe, bot es viele der heutigen Features noch nicht…

  6. Pingback:Artikelbezogene Zugriffsberechtigungen im MediaWiki » Stefan Macke

  7. Hallo, ich habe

    $wgGroupPermissions[‘user’][‘*’] = false;
    $wgGroupPermissions[‘edv’][‘*’] = true;

    in die LocalSettings.php eingetragen, aber man kann immer noch anonym Seiten betrachten und ändern. Immerhin wird in der Spezial:Benutzerrechte die Gruppe “edv” angezeigt.

    Wurde da in den neuen MediaWiki-Versionen etwas geändert? Wie kann ich anonyme Nutzer aussperren?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax