Englisch:
|
PmWikiDe /
Passwörter verwalten
Administratoren
< E-Mail Nachricht bei geänderten Seiten (neu) | Dokumentations-Index | Auffinden von verwaisten und fehlenden Seiten > PmWiki hat eine eingebaute Unterstützung für den Schutz mitPasswö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. PasswortgrundlagenPmWiki unterstützt verschiedene Zugangsstufen zu Wikiseiten, Autorisierungsebenen genannt:
Seiten haben ihre Passwörter als "Seiteneigenschaften", welche mittels Anhängen an die URL von 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:
Ein Site-weite Passwörter setzenEines der ersten Dinge, die ein Administrator nach dem Installieren tun sollte, ist ein Beachten Sie, dass dafür der crypt()-Aufruf notwendig ist — PmWiki speichert und behandelt alle Passwörter intern als verschlüsselte Strings. Siehe den Crypt-Abschnitt 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 $DefaultPasswords ['edit'] = crypt('bearbeiten_passwort');
Ähnlich kann man für jede der verfügbaren Aktionen ein site-weites Passwort setzen, d. h. $DefaultPasswords ['read'] = array(crypt('alpha'), crypt('beta'));
$DefaultPasswords ['edit'] = crypt('beta');
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. Passwörter durch Referenzen setzenPasswö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_MeinPasswort2
und in der lokalen Konfigurationsdatei setzt man das eigentliche Passwort mit Zeilen wie diesen: $DefaultPasswords ['MeinPasswort2'] = array(crypt('secret'), '@admins');
$DefaultPasswords ['MeinPasswort9'] = array('$1$NuBV/Mcc$GG3J60h.TLczUTRKhoVPM.');
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'] = crypt('youradminpassword'); $DefaultPasswords['attr'] = crypt('yourattrpassword'); Passwörter verschlüsseln in config.phpEinen Pferdefuß hat es, die crypt()-Funktion in der config.php direkt zu verwenden, um Passwörter zu setzen, schließlich kann jeder, der die Möglichkeit hat, in die config.php hineinzusehen, das unverschlüsselte Passwort sehen. Wenn zum Beispiel die config.php $DefaultPasswords ['admin'] = crypt('meingeheimnis');
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 $1$sG2.F8..$g/tgMqCFlIKj1iFkcAAxx0
dazu eine Zeile, die man fast eins zu eins in die config.php kopieren kann:
Man muss nur noch Beachten Sie, dass in dieser verschlüsselten Form der Funktionsname "crypt" 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 sieht, wird er das Passwort durch bloßes Ansehen des verschlüsselten Passwortes nicht herausbekommen. Crypt liefert für ein und dasselbe Passwort verschiedene Verschlüsselungen — das ist normal, und macht es um so schwieriger, das eigentliche Passwort herauszubekommen. Passwörter entfernenUm ein Sitepasswort vollständig zu entfernen, so wie das standardmäßig gesperrte Passwort für 'upload', setzt man einen leeren String ein: $DefaultPasswords ['upload'] = '';
Es kann auch das Sonderpasswort "@nopass" (wird in der Ein Passwort ungültig machen oder aufhebenWenn ein Passwort kompromittiert ist und der Wikiadministrator das Passwort schnell ungültig machen möchte, ist das Folgende in der local/config.php 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 Skripte mit eigenen Aktionen bereitstellen, können dies auch benutzen, aber ich begrenze das Beispiel auf eine (standardmäßig) nicht geschützte Es gibt einige Lösungen dafür:
Wenn man das Passwort zusätzlich in die Attributes-Seite setzen möchte:
Im allgemeinen gilt: fügt man einem Aktionsnamen in dem 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' << E-Mail Nachricht bei geänderten Seiten (neu) | Dokumentationsindex | Auffinden von verwaisten und fehlenden Seiten >> 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 crypt()-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 config.php setzt.
Wie benutze ich passwd-formatierte Dateien (wie .htpasswd) für die Authentifizierung? Siehe AuthUser, Cookbook:HtpasswdForm or Cookbook:UserAuth. 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
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-( Legen Sie einfach eine neue Seite an (Site.AttrForm?), und fügen Sie die folgende Zeile in config.php ein:
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. 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
< E-Mail Nachricht bei geänderten Seiten (neu) | Dokumentations-Index | Auffinden von verwaisten und fehlenden Seiten >
Übersetzung von PmWiki.PasswordsAdmin
Originalseite auf PmWikiDe.PasswordsAdmin - Backlinks |