Extension:Lockdown
Wenn du Zugriffsbeschränkungen für einzelne Seiten oder Teilbereiche benötigst, solltest du ein entsprechendes Content-Management-Paket installieren. MediaWiki wurde nicht so geschrieben, dass es Zugriffsbeschränkungen für einzelne Seiten bietet, und fast alle Hacks oder Patches, die dies versprechen, haben wahrscheinlich irgendwo einen Fehler, der dazu führen könnte, dass vertrauliche Daten offengelegt werden. Wir sind nicht dafür verantwortlich, dass etwas durchsickert.
Für weitere Details siehe Security issues with authorisation extensions |
Lockdown Freigabestatus: stabil |
|
---|---|
Einbindung | Benutzerrechte |
Beschreibung | Erlaubt die Implementierung von Gruppenberechtigungen pro Namensraum |
Autor(en) | Daniel Kinzler (DuesentriebDiskussion) |
MediaWiki | 1.31+ |
PHP | 5.5+ |
Lizenz | GNU General Public License 2.0 oder neuer |
Herunterladen | README |
|
|
Quarterly downloads | 354 (Ranked 8th) |
Übersetze die Lockdown-Erweiterung, wenn sie auf translatewiki.net verfügbar ist | |
Probleme | Offene Aufgaben · Einen Fehler melden |
Die Lockdown-Erweiterung implementiert eine Möglichkeit, den Zugriff auf bestimmte Namensräume und spezielle Seiten auf eine bestimmte Gruppe von Benutzern zu beschränken. Dies bietet ein feiner abgestuftes Sicherheitsmodell als das der Standardeinstellungen $wgGroupPermissions und $wgNamespaceProtection .
Die folgenden Seiten über das Sicherheitsmodell, das von MediaWiki standardmäßig verwendet wird, können hilfreich sein, um die folgenden Anweisungen zu verstehen:
Installation
- Die Erweiterung herunterladen und die Datei(en) in ein Verzeichnis namens
Lockdown
im Ordnerextensions/
ablegen.
Entwickler und Code-Beitragende sollten stattdessen die Erweiterung von Git installieren, mit:cd extensions/
git clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Lockdown - Folgenden Code am Ende deiner LocalSettings.php -Datei einfügen:
wfLoadExtension( 'Lockdown' );
- Konfiguriere nach Bedarf
- Erledigt – Navigiere zu Special:Version in deinem Wiki, um zu überprüfen, ob die Erweiterung erfolgreich installiert wurde.
Beispiel
Um Lockdown zu verwenden:
- den Zugriff auf Special:Export für angemeldete Benutzer (registrierte Benutzer) verhindern
- Beschränkung der Bearbeitung des Projektnamensraumes auf angemeldete Benutzer (registrierte Benutzer)
Du kannst dann Folgendes verwenden:
$wgSpecialPageLockdown['Export'] = [ 'user' ];
$wgNamespacePermissionLockdown[NS_PROJECT]['edit'] = [ 'user' ];
Siehe unten für eine Erklärung und weitere Beispiele.
Konfiguration
Beachte, dass die Lockdown-Erweiterung nur verwendet werden kann, um den Zugang zu beschränken, nicht um ihn zu gewähren. Wenn der Zugriff durch eine integrierte Einstellung von MediaWiki verweigert wird, kann er mit der Lockdown-Erweiterung nicht zugelassen werden.
$wgSpecialPageLockdown
Mit $wgSpecialPageLockdown
kannst du für jede spezielle Seite festlegen, welche Benutzergruppen Zugriff darauf haben.
Wenn du z.B. die Nutzung von Special:Export auf eingeloggte Benutzer beschränken willst, verwende dies in LocalSettings.php
:
$wgSpecialPageLockdown['Export'] = [ 'user' ];
Beachte, dass einige Spezialseiten "von Haus aus" eine bestimmte Erlaubnis benötigen.
Für Special:MovePage, das zum Verschieben von Seiten verwendet werden kann, ist zum Beispiel die Berechtigung "move
" erforderlich (die standardmäßig nur eingeloggten Benutzern gewährt wird).
Diese Einschränkung kann nicht mit der Lockdown-Erweiterung außer Kraft gesetzt werden.
Einige spezielle Seitentitel werden nicht so groß geschrieben, wie sie im Wiki erscheinen. Zum Beispiel ist Special:RecentChanges intern Recentchanges, also brauchst du, um es einzuschränken:
$wgSpecialPageLockdown['Recentchanges'] = [ 'user' ];
Eine vollständige Liste der speziellen Seitentitel findest du in der "MessagesEn.php"-Datei ($specialPageAliases
-Array) oder verwende alternativ das "siteinfo"-API-Modul wie z.B. /api.php?action=query&meta=siteinfo&siprop=specialpagealiases in deinem Wiki.
$wgActionLockdown
Mit $wgActionLockdown
kannst du für jede Aktion angeben, welche Benutzergruppen Zugriff darauf haben.
Um zum Beispiel die Nutzung der Verlaufsseite auf eingeloggte Benutzer zu beschränken, verwende dies in LocalSettings.php:
$wgActionLockdown['history'] = [ 'user' ];
Note that some actions can not be locked down this way. In particular, it will not work for the ajax
action.
$wgNamespacePermissionLockdown
$wgNamespacePermissionLockdown
lets you restrict which user groups have which permissions on which namespace. For example, to grant only members of the sysop group write access to the project namespace, use this:
$wgNamespacePermissionLockdown[NS_PROJECT]['edit'] = [ 'sysop' ];
Wildcards for either the namespace or the permission (but not both at once) are supported. More specific definitions take precedence:
$wgNamespacePermissionLockdown[NS_PROJECT]['*'] = [ 'sysop' ];
$wgNamespacePermissionLockdown[NS_PROJECT]['read'] = [ '*' ];
$wgNamespacePermissionLockdown['*']['move'] = [ 'autoconfirmed' ];
The first two lines restrict all permissions in the project namespace to members of the sysop group, but still allow reading to anyone. The third line limits page moves in all namespaces to members of the autoconfirmed group.
Note that this way, you cannot grant permissions that have not been allowed by the build-in $wgGroupPermissions setting. The following does not allow regular users to patrol edits in the main namespace:
$wgNamespacePermissionLockdown[NS_MAIN]['patrol'] = [ 'user' ];
Instead, you would have to grant this right in $wgGroupPermissions first, and then restrict it again using $wgNamespacePermissionLockdown:
$wgGroupPermissions['user']['patrol'] = true;
$wgNamespacePermissionLockdown['*']['patrol'] = [ 'sysop' ];
$wgNamespacePermissionLockdown[NS_MAIN]['patrol'] = [ 'user' ];
Note that when restricting read-access to a namespace, the restriction can easily be circumvented if the user has read access to any other namespace: by including a read-protected page as a template, it can be made visible. To avoid this, you would have to forbid the use of pages from that namespace as templates, by adding the namespace's ID to $wgNonincludableNamespaces :
$wgNamespacePermissionLockdown[NS_PROJECT]['read'] = [ 'user' ];
$wgNonincludableNamespaces[] = NS_PROJECT;
You can of course also use Lockdown with custom namespaces defined using $wgExtraNamespaces :
// define custom namespaces
$wgExtraNamespaces[100] = 'Private';
$wgExtraNamespaces[101] = 'Private_talk';
// restrict "read" permission to logged in users
$wgNamespacePermissionLockdown[100]['read'] = [ 'user' ];
$wgNamespacePermissionLockdown[101]['read'] = [ 'user' ];
// prevent inclusion of pages from that namespace
$wgNonincludableNamespaces[] = 100;
$wgNonincludableNamespaces[] = 101;
Note that custom namespaces should always be defined in pairs, the namespace proper (with an even id), and the associated talk namespace (with an odd id).
If you want to use constants to refer to your namespaces, you need to define them:
// define constants for your custom namespaces, for a more readable configuration
define('NS_PRIVATE', 100);
define('NS_PRIVATE_TALK', 101);
// define custom namespaces
$wgExtraNamespaces[NS_PRIVATE] = 'Private';
$wgExtraNamespaces[NS_PRIVATE_TALK] = 'Private_talk';
// restrict "read" permission to logged in users
$wgNamespacePermissionLockdown[NS_PRIVATE]['read'] = [ 'user' ];
$wgNamespacePermissionLockdown[NS_PRIVATE_TALK]['read'] = [ 'user' ];
// prevent inclusion of pages from that namespace
$wgNonincludableNamespaces[] = NS_PRIVATE;
$wgNonincludableNamespaces[] = NS_PRIVATE_TALK;
You could also use array_fill() to restrict multiple namespaces at once, e.g. if you wanted to restrict namespaces 0 to 2009 to editing by sysops only:
$wgNamespacePermissionLockdown = array_fill( 0, 2010, [ 'edit' => [ 'sysop' ] ] );
$wgNamespacePermissionLockdown vs $wgActionLockdown
$wgActionLockdown
is checked considerably sooner (in the MediaWikiPerformAction hook) in the request-handling process than $wgNamespacePermissionLockdown
(which is checked in the getUserPermissionsErrors hook).
If an action that $wgActionLockdown
does not permit is attempted, a permission error is displayed. Likewise, $wgNamespacePermissionLockdown
lets the end user know which groups are allowed to perform the action.
Gruppen verwalten
You can control which user belongs to which groups with the page Special:Userrights. Only existing groups will be proposed, but you can "create" a new group by creating an entry for it in $wgGroupPermissions (even if you don't actually need to set a permission there, but it has to appear on the left hand side of the array). For example:
$wgGroupPermissions['somegroupname']['read'] = true;
For more information, see Help:User rights, Manual:User rights, and Manual:User rights management.
Zusätzliche Maßnahmen
Images and other uploaded files still can be seen and included on any page. Protections on the Image namespace do not prevent that. See Manual:Image Authorisation for information on how to prevent unauthorized access to images. See also:
Bekannte Probleme
Lockdown is known to be broken for MW 1.27.x to 1.30.x [1]. Possible side-effects of using it include:
- Incomplete list of namespaces showing under the Advanced tab of Special:Search and on the special page for ReplaceText
- Searchbox no longer offering autocompletion for certain namespaces
A workaround may be to list all namespaces under $wgContentNamespaces , but success is not guaranteed. Another temporary solution is to use a version before the breaking commits, as detailed in Topic:Tr4xxpln3fnpz3eu.
Siehe auch
- Category:User rights extensions
- GroupManager (BlueSpice) - for adding, editing and deleting user groups
- PermissionManager (BlueSpice) - for administering user rights to user groups
- UserProtect - Allows per-user per-right per-page protection
- PageOwnership - Multi-layered permission manager, whole wiki or specific pages, with friendly interface
- AccessControl - Allows restricting access to specific pages and files
- CategoryLockdown - Allows restricting access by category and group
Diese Erweiterung ist in den folgenden Softwarepaketen enthalten und/oder wird von den folgenden Wiki-Farmen, bzw. Wiki-Hostern verwendet: Dies ist keine maßgebliche Liste. Softwarepakete und/oder Wiki-Farmen, bzw. Wiki-Hoster nutzen diese Erweiterung ggf., obwohl sie nicht in dieser Liste enthalten sind. Prüfe daher stets die Nutzung im verwendeten Softwarepaket und/oder bei der Wiki-Farm, bzw. dem Wiki-Hoster. |