für die Liste aller Seiten
Administratoren
PmWiki hat eine eingebaute Unterstützung für den Schutz mit Passwörtern für verschiedene Bereiche der Wiki-Site. Passwörter können auf Einzelseiten, auf Wikigruppen oder die gesamte Website angewendet werden. Das hier beschriebene Passwortschutz-System ist nur ein kleiner Ausschnitt des kompletten Sicherheitssystems. Weitere Informationen dazu finden sich auf der Seite Sicherheit.
Autoren können PmWiki, wie in Passwörter beschrieben, dazu benutzen um an Einzelseiten und Wikigruppen Passwörter anzuhängen. Der WikiAdministrator kann jedenfalls auch Passwörter in den Dateien für lokale Anpassungen festlegen, so wie weiter unten beschrieben. Anmerkung: Man kann Passwörter nicht zuverlässig in Seiten- oder Gruppenanpassungsdateien setzen. Siehe im FAQ-Abschnitt wegen der Details.
Passwortgrundlagen
PmWiki unterstützt verschiedene Zugangsstufen zu Wikiseiten, Autorisierungsebenen genannt:
read-Passwörter erlauben das Anschauen der Inhalte von Wikiseiten.
edit-Passwörter kontrollieren das Bearbeiten und Verändern von Wikiseiten (effektiv gegen Spam).
attr-Passwörter kontrollieren, wer Passwörter auf Seiten überhaupt setzen darf (und künftig in PmWiki bereit gestellte Eigenschaften).
upload-Passwörter kontrollieren, wenn das Hochladen von Dateien aktiviert ist, das Hochladen von Dateien und Anhängen.
- Ergänzend können alle verfügbaren Aktionen durch Passwörter autorisiert werden.
- Zum Schluß gibt es noch das
admin-Passwort, welches einem Administrator erlaubt, Passwörter jeder Einzelseite oder Gruppe zu überschreiben oder außer Kraft zu setzen.
Seiten haben ihre Passwörter als "Seiteneigenschaften", welche mittels Anhängen an die URL von ?action=attr zugänglich gemacht werden. Passwörter für Gruppen stehen auf einer besonderen, für jede Gruppe existierenden, "GroupAttributes" genannten Seite. Globale, die Website übergreifende Passwörter werden vom $DefaultPasswords-Array (Datenfeld) aus gesteuert. Alle Passwörter werden in einem verschlüsselten Format gespeichert, so dass andere Benutzer auf dem System befindliche Dateien, die eines Passworts bedürfen, nicht durch einfaches Browsen oder Erstöbern erreichen können.
Was bedeuten "leeres Passwort", "kein Passwort" und "gesperrtes Passwort".
gekennzeichnet (hier: geheim).
Fehlt die Zeile (kein Passwort) oder ist der Eintrag passwdedit= (leeres Passwort), kann die Seite bearbeitet werden – es sei denn, weiterreichende (gruppen- oder site-weite) Beschränkungen bestehen. Ist der Eintrag passwdedit=* ist das Passwort gesperrt und ein Bearbeiten ist unmöglich.
Per Voreinstellung hat PmWiki die folgenden Passworteinstellungen:
$DefaultPasswords ist mit leeren (also ohne) read-, edit-, und attr-Passwörter eingestellt.
- Das
admin- und das upload-Passwort sind zunächst gesperrt.
- Die Main- und die PmWiki-Gruppe haben ein gesperrtes
attr-Passwort in ihren jeweiligen GroupAttributes-Seiten, um Autoren daran zu hindern, Passwörter auf Seiten in diesen Gruppen zu setzen. Um diese Passwörter zu verändern, wird Main.GroupAttributes?action=attr oder PmWiki.GroupAttributes?action=attr mit den entsprechenden Rechten gebraucht.
- Die Seiten der Site-Gruppe, mit Ausnahme der SideBar, sind gesichert gegen Bearbeiten; die Site.SideBar-Seite erfordert das
admin- oder das site-weite edit-Passwort.
Ein admin-Passwort kann benutzt werden, um die "gesperrten" Passwörter zu überwinden, darüber hinaus funktioniert gar kein Passwort. Natürlich kann der Administrator die gesperrten Passwörter setzen. Dann funktionieren diese Passwörter.
Site-weite Passwörter setzen
Eines der ersten Dinge, die ein Administrator nach dem Installieren tun sollte, ist ein admin-Passwort setzen.
Um das websiteweite Administrator-Passwort auf "meingeheimnis" zu setzen, kann der Administrator die folgende Zeile in die Datei local/config.php setzen:
Beachten Sie, dass dafür der pmcrypt()-Aufruf notwendig ist – PmWiki speichert und behandelt alle Passwörter intern als verschlüsselte Strings. Siehe den Abschnitt 'Passwörter verschlüsseln' weiter unten wegen Details, wie man das Klartext-Passwort aus der config.php-Datei eliminieren kann.
Um die ganze Site nur für solchen Benutzer bearbeitbar zu machen, die ein Bearbeiten-Passwort kennen, fügt man eine Zeile wie die Folgende in die local/config.php-Datei ein:
Ähnlich kann man für jede der verfügbaren Aktionen ein site-weites Passwort setzen, d. h. $DefaultPasswords['read'], $DefaultPasswords['edit'] und $DefaultPasswords['upload'] zur Kontrolle des Standard-read-, -edit-, und -upload-Passworts für die ganze Site. Diese Standardpasswörter werden bei Seiten und Gruppen verwendet, für die kein Passwort gesetzt ist, und als zusätzliches Passwort für Seiten, für die ein Passwort gesetzt ist. Auch darf jedes der $DefaultPasswords ein Array verschlüsselter Passwörter enthalten.
Das heißt, dass sowohl "alpha" als auch "beta" zum Betrachten von Seiten verwendet werden können, aber nur "beta" erlaubt jemandem das Bearbeiten der Seiten. Da PmWiki Passwörter, die einmal eingegeben wurden, während einer Sitzung behält, erlaubt das "beta"-Passwort sowohl Betrachten als auch Bearbeiten, während das "alpha"-Passwort nur Betrachten erlaubt. Eine Person ohne eines der Passwörter könnte Seiten noch nicht einmal ansehen.
Um eine Aktion zu sperren, sodass nur Admins sie ausführen können, benutzen Sie '@lock' als Wert, ohne pmcrypt:
Passwörter durch Referenzen setzen
Dies ist ein unbeabsichtigtes Feature.
Passwörter durch Referenzen zu setzen, erlaubt dem Administrator, das Passwort für einen ganzen Satz von Seiten zu ändern, das geht so einfach wie das Ändern von site-weiten Passwörtern. (Andernfalls müsste man die Attribute jeder Seite individuell ändern.) Man gibt in den Seiten- oder Gruppen-Attributen ein:
@_site_MeinLevel2
und in der lokalen Konfigurationsdatei setzt man das eigentliche Passwort mit Zeilen wie diesen:
Beachten Sie, dass Passwörter, die durch Referenzen in einer Konfigurationsdatei gesetzt werden, gegenwärtig nicht als site-weite Passwörter verwendet werden können. Doch können Sie Ihr @_site_level ausdrücklich im Gruppenattribut aller Gruppen einsetzen – mit dem gleichen Effekt. Einmal als Gruppenattribut eingesetzt wird das Passwort auf alle Seiten der Gruppe angewendet, es sei denn, es wird überschrieben, wie jedes anderen Passwort auch.
Identitätsbasierte Autorisierung (Benutzername/Passwort-Logins, AuthUser)
Anders als viele Systeme, die identitätsbasierte Systeme zu Kontrolle der Seitenzugriffe einsetzen (d. h. sie benutzen einen separaten Benutzenamen und ein Passwort für jeder Person), kommt PmWiki mit einem passwortbasierten System aus, wie es oben beschrieben wurde.
Generell sind passwortbasierte Systeme einfacher zu verwalten, da sie den administrativen Overhead des Erstellens von Benutzerkonten, des Restaurierens verlorengegangener Passwörter, und des Verzahnens der Benutzernamen mit erlaubten Aktionen vermeiden.
Allerdings erweitert PmWikis authuser.php-Skript das passwortbasierte System um den Zugriff auf Seiten, auf der Basis einer Benutzername-Passwort-Kombination zu erlauben. Siehe AuthUser wegen weiterer Details über die Zugriffskontrolle auf Seiten, basierend auf Benutzeridentität.
Sicherheitslöcher ...
Administratoren müssen sorgfältig planen, wo Passwörter angewendet werden, um das Öffnen unbeabsichtigter Sicherheitslöcher zu vermeiden. Wenn Ihr Wiki offen ist (jeder kann lesen und schreiben), scheint das nicht beunruhigend zu sein, außer ein böswilliger oder verwirrter Benutzer kann ein Ansehen-Passwort für eine Gruppe setzen und die Gruppe vollständig unzugänglich für alle andern Benutzer machen.
Als das Allerwenigste sollte auch ein offenes Wiki ein site-weites "admin"-Passwort und ein site-weites "attr"-Passwort in der config.php-Datei gesetzt haben. Die sample-config.php-Datei, die mit PmWiki ausgeliefert wird, zeigt, dass (nur) die PmWiki- und die Main-Gruppe "attr" standardmäßig gesperrt haben, aber wenn jemand eine neue Gruppe anlegt, ist "attr" frei. Administratoren müssen jedes Mal daran denken, das "attr"-Passwort für jede neue Gruppe zu setzen (wenn es gewünscht ist).
Eine einfachere Lösung ist, diese Zeilen in die config.php-Datei zu schreiben:
$DefaultPasswords['admin'] = pmcrypt('youradminpassword');
$DefaultPasswords['attr'] = pmcrypt('yourattrpassword');
Passwörter verschlüsseln in config.php
Einen Pferdefuß hat es, die pmcrypt()-Funktion in der config.php-Datei direkt zu verwenden, um Passwörter zu setzen, schließlich kann jeder, der die Möglichkeit hat, in die config.php-Datei hineinzusehen, das unverschlüsselte Passwort sehen. Wenn zum Beispiel die config.php-Datei
enthält, ist das "meingeheimnis"-Passwort als Klartext für andere zu sehen. Allerdings kann ein Wikiadministrator eine verschlüsselte Form des Passwortes direkt eintragen und benutzen, indem er ?action=crypt an irgend einen URL einer Wikiseite im Ziel-Wiki anfügt (oder springen Sie eben zu PasswordsAdmin?action=crypt in Ihrem eigenen Wiki).
Diese Aktion präsentiert ein Formular, in das man sein Passwort einträgt und das eine verschlüsselte Version des Passwortes erzeugt und anzeigt für den Gebrauch in der config.php-Datei. Wenn also das Passwort "meingeheimnis" übergeben wird, liefert PmWiki einen String zurück, der etwa so aussieht:
$1$sG2.F8..$g/tgMqCFlIKj1iFkcAAxx0
dazu eine Zeile, die man fast eins zu eins in die config.php-Datei kopieren kann:
Man muss nur noch 'type' durch 'admin'ersetzen.
Beachten Sie, dass in dieser verschlüsselten Form der Funktionsname "pmcrypt" und die Klammern entfernt sind, da das Passwort bereit verschlüsselt ist. Auch muss das Passwort in einfache Anführungszeichen gesetzt werden.
In diesem Beispiel ist das Passwort, das der Administrator benutzt, noch immer "meingeheimnis", aber wenn jemand in die config.php-Datei sieht, wird er das Passwort durch bloßes Ansehen des verschlüsselten Passwortes nicht herausbekommen.
?action=crypt liefert für ein und dasselbe Passwort verschiedene Verschlüsselungen – das ist normal, und macht es um so schwieriger, das eigentliche Passwort herauszubekommen.
Bitte beachten Sie, dass Sie das Passwort mit ?action=crypt auf dem Wiki erzeugen, wo es gebraucht werden soll. Ein Passwort, das auf einem System erzeugt wurde, kann auf einem anderen System funktionieren – oder auch nicht.
Passwörter entfernen
Um ein Sitepasswort vollständig zu entfernen, so wie das standardmäßig gesperrte Passwort für 'upload', setzt man einen leeren String ein:
Es kann auch das Sonderpasswort "@nopass" (wird in der $AllowPassword Variablen festgelegt) mittels ?action=attr gesetzt werden. Dadurch wird eine nicht passwortgeschützte Seite in einer passwortgeschützten Gruppe erstellt oder eine nicht passwortgeschützte Gruppe innerhalb einer passwortgeschützten Website.
Ein Passwort ungültig machen oder aufheben
Wenn ein Passwort kompromittiert ist und der Wikiadministrator das Passwort schnell ungültig machen möchte, ist das Folgende in der ''local/config.php''-Datei eine schnelle Lösung:
$ForbiddenPasswords = array('secret', 'tanstaafl');
if (in_array(@$_POST['authpw'], $ForbiddenPasswords))
unset($_POST['authpw']);
Das hindert "secret" und "tanstaafl" daran, je wieder als ein gültiges Autorisierungspasswort angenommen zu werden ohne Rücksicht darauf, welche Seite es nutzt.
Siehe auch
Aktionen schützen (Beispiel)
Jede verfügbare Aktion kann durch ein Passwort geschützt werden.
Kochbuchautoren, die Skripten mit eigenen Aktionen bereitstellen, können dies auch benutzen, aber ich begrenze das Beispiel auf eine (standardmäßig) nicht geschützte ?action=source. Diese Aktion zeigt die Wikiquelle der aktuellen Seite. Manchmal möchte man das nicht, insbesondere um E-Mail zu schützen oder man benutzt ein paar bedingte Texte, die nicht einfach vor Jedem aufgedeckt werden sollen oder nur von Personen, die das Recht haben, die Seite zu bearbeiten.
Es gibt einige Lösungen dafür:
- Sie begrenzen "source" nur auf Verfasser und fügen das zur local/config.php-Datei hinzu:
$HandleAuth['source'] ='edit';
- Um "source" mit einem eigenen Passwort zu versehen, fügen Sie das hinzu:
$HandleAuth['source'] ='source';
$DefaultPasswords['source'] = pmcrypt('secret'); # siehe oben
Wenn Sie das Passwort zusätzlich in die Attributes-Seite setzen möchten:
$PageAttributes['passwdsource'] = "$['Set new source password']";
Im allgemeinen gilt: Fügen Sie einem Aktionsnamen in dem $PageAttributes-Array den Präfix 'passwd' hinzu, zeigt das an, Sie möchten für das gegebene Feld, dass es beim Speichern verschlüsselt wird.
Der volle Satz von Schritten zum Hinzufügen einer neuen Passworthandhabung für eine Aktion wie "diff" wäre:
# Füge ein neues (verschlüsseltes) Feld zur 'attr'-Seite hinzu
$PageAttributes['passwddiff'] = "$['Set new history password']";
# lösche das Standardpasswort für 'diff'
$DefaultPasswords['diff'] = '';
# Sage PmWiki, dass das 'diff'-Passwort die Aktion 'diff' erlaubt
$HandleAuth['diff'] = 'diff';
# Sage PmWiki, dass das 'read-Passwort
# (oder alternativ das 'edit'-Passwort)
# auch reicht, um 'diff' zu ermöglichen.
# natürlich geht auch das 'admin'-Passwort.
$AuthCascade['diff'] = 'read'; ## or 'edit'
FAQ
Es scheint ein Standardpasswort zu geben, welches ist es?
Es gibt keine gültigen Passwörter, bis Sie eines setzen. Site-weite Passwörter setzen erklärt, wie man eines setzt.
PmWiki kommt "out of the box" mit dem
$DefaultPasswords['admin'] auf '*' gesetzt. Das heißt nicht, das Passwort ist ein Sternchen, es bedeutet, das Standard-Administrator-Passwort muss etwas sein, das verschlüsselt zum Sternchen wird. Da das für die
pmcrypt()-Funktion unmöglich ist, jemals einen ein-Zeichen-langen verschlüsselten Wert zurückzugeben, ist das Administrator-Passwort tatsächlich gesperrt, bis der Administrator ein Passwort in der
config.php-Datei setzt.
Wie benutze ich passwd-formatierte Dateien (wie .htpasswd) für die Authentifizierung?
Siehe AuthUser, Cookbook:HtpasswdForm oder Cookbook:UserAuth2.
Gibt es irgendetwas, das ich in das GroupAttributes-Feld eintragen kann, was 'das gleiche wie das Administrator-Passwort' bedeutet? Wenn nicht, gibt es irgendetwas, das ich in die config.php-Datei eintragen kann, um ebendas zu erreichen?
Geben Sie '@lock' in GroupAttributes?action=attr ein, damit diese Gruppe ein Administrator-Passwort benötigt.
Wie schütze ich – sagen wir mal – alle RecentChanges-Seiten gegen Bearbeiten?
Siehe Security#wikivandalism
Wie kann ich alle Seiten in einer Gruppe gegen Ansehen ('read') schützen, mit Ausnahme der Startseite (HomePage), wenn ich dafür Konfigurationsdateien benutzen will?
Wie in Individuelle Einstellungen pro Gruppe beschrieben, sollten Per-Gruppen- oder Per-Seiten-Konfigurationsdateien nicht benutzt werden, um Passwörter zu setzen. Der Grund ist, dass Per-Gruppen- oder Per-Seiten-Konfigurationsdateien nur für die aktuelle Seite geladen werden. Wenn $DefaultPasswords['read'] in der local/GruppeA.php-Datei gesetzt ist, dann kann jemand eine Seite in einer anderen Gruppe nutzen, um Inhalte von Seiten aus GruppeA zu lesen. Zum Beispiel könnte Main.WikiSandbox dies enthalten:
(:include GroupA.SomePage:)
und weil die GruppeA.php-Datei nicht geladen wird (wir sehen uns ja Main.WikiSandbox an → local/Main.php), ist kein Ansehen-Passwort gesetzt.
Wie kann ich das Anlegen neuer Seiten mit einem Passwort schützen?
Siehe Cookbook:LimitWikiGroups, Cookbook:NewGroupWarning, Cookbook:LimitNewPagesInWikiGroups.
Wie ändere ich den Schirm mit der Aufforderung zum Passwort-Eingeben?
Wenn Ihre Frage ist, wie ändere ich die Seite ... Bearbeiten Sie Site.AuthForm. Wenn ihre Frage dahingeht, wie man umstellt, welche Seite aufgerufen wird, wenn man nach einem Passwort gefragt wird, suchen Sie Hilfe bei Cookbook:CustomAuthForm.
Wie ändere ich die Aufforderung auf dem Attribute-(?action=attr)-Schirm?
Legen Sie einfach eine neue Seite an (Site.AttrForm?), und fügen Sie die folgende Zeile in die config.php-Datei ein:
$PageAttrFmt = 'page:Site.AttrForm';
Beachten Sie, dass das nur den Text über den Eingabefeldern ändert und nicht die Eingabefelder selbst – die Eingabefelder muss man getrennt davon behandeln. Siehe Cookbook:CustomAttrForm wegen weiterer Informationen.
Ich bekomme einen http error 500 "Internal Server Error", wenn ich versuche, mich einzuloggen. Was ist falsch?
Das kann passieren, wenn das verschlüsselte Passwort nicht auf dem Server erzeugt wird, auf dem PmWiki gehostet wird.
Die crypt-Funktion hat sich während der Entwicklung von PHP geändert, d. h. dass ein Passwort, das mit PHP 5.2 verschlüsselt wurde, nicht mit PHP 5.1 entschlüsselt werden kann, aber PHP 5.2 kann Passwörter entschlüsseln, die mit PHP 5.1 verschlüsselt wurden.
Diese Situation passiert normalerweise, wenn Sie Alles auf Ihrem lokalen Rechner mit der letzten PHP-Version vorbereitet haben und Sie die Passwörter auf einen Webserver hochladen, der mit einer älteren Version läuft.
Der gleiche Fehler tritt auf, wenn Sie verschlüsselte Passwörter in die local/config.php-Datei einfügen.
Lösung: Erzeugen Sie die Passwörter auf dem System mit der ältesten PHP-Version und benutzen Sie sie auf allen anderen Systemen.
Ich möchte, dass meine Benutzer nur ein Bearbeiten-Passwort erstellen müssen, das dann automatisch auch als ihre 'upload'- und 'attr'-Passwörter gilt, ohne dass sie das getrennt setzen müssen. Wie mache ich das?
Indem Sie $HandleAuth wie hier einrichten:
$HandleAuth['upload'] = 'edit';
// Um u. a. eine WikiSandbox vorm Ändern ihres 'attr'-Rechts zu schützen außer durch den
// Admin (aber den Verfassern das Ändern ihrer eigenen Seiten/Gruppen zu erlauben)
// And to prevent a WikiSandbox from having it's 'attr' permissions changed
// except by the admin (but allowing editors to change it on their own pages/group)
if(($group=="Site") || ($group=="Main") || ($group=="Category") ||
($group=="SiteAdmin") || ($group=="PmWiki") ) {
// setze 'attr' auf das 'admin'-Passwort für alle Main-Admin-Seiten
$HandleAuth['attr'] = 'admin';
} else {
// Wer Bearbeiten kann, kann auch Attribute setzen
$HandleAuth['attr'] = 'edit';
}
für die Liste aller Seiten
