Extension:Lockdown
Si vous avez besoin de restrictions d'accès par page ou par portion de page, il vous est conseillé d'installer un paquet de gestion du contenu approprié. MediaWiki n'est pas écrit pour fournir des restrictions d'accès sur une page donnée, et la plupart des contournements ou patchs promettant de l'ajouter auront de fortes chances d'avoir des failles, ce qui pourrait mener à des divulgations de données confidentielles. Nous ne sommes pas responsable d'une fuite quelconque.
Pour plus de détails, voir Problèmes de sécurité avec les extensions d'autorisation |
Lockdown État de la version : stable |
|
---|---|
Implémentation | Droits utilisateur |
Description | Implémente les autorisations de groupe par espace de noms |
Auteur(s) | Daniel Kinzler (Duesentriebdiscussion) |
MediaWiki | 1.31+ |
PHP | 5.5+ |
Licence | Licence publique générale GNU v2.0 ou supérieur |
Téléchargement | README |
|
|
Téléchargements trimestriels | 354 (Ranked 8th) |
Traduire l’extension Lockdown sur translatewiki.net si elle y est disponible | |
Problèmes | Tâches ouvertes · Signaler un bogue |
L'extension Lockdown implémente un moyen de restreindre l'accès à des espaces de noms spécifiques et des pages spéciales à un ensemble donné de groupes d'utilisateurs. Cela fournit un modèle de sécurité plus finement grainé que celui fourni par les paramètres par défaut $wgGroupPermissions et $wgNamespaceProtection .
Les pages suivantes sur le modèle de sécurité utilisé par MediaWiki par défaut peuvent être utiles pour comprendre les instructions ci-dessous :
Installation
- Téléchargez et placez le(s) fichier(s) dans un répertoire appelé
Lockdown
dans votre dossierextensions/
.
Les développeurs et les contributeurs au code doivent à la place installer l'extension à partir de Git en utilisant:cd extensions/
git clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Lockdown - Ajoutez le code suivant à la fin de votre fichier LocalSettings.php :
wfLoadExtension( 'Lockdown' );
- Configuration requise
- Fait – Accédez à Special:Version sur votre wiki pour vérifier que l'extension a bien été installée.
Exemple
Pour utiliser le verrouillage pour :
- empêcher l'accès à Special:Export aux utilisateurs connectés (utilisateur inscrit)
- limiter la modification de l'espace de noms du projet aux utilisateurs connectés (utilisateurs enregistrés)
Vous pouvez ensuite utiliser les éléments suivants :
$wgSpecialPageLockdown['Export'] = [ 'user' ];
$wgNamespacePermissionLockdown[NS_PROJECT]['edit'] = [ 'user' ];
Voir ci-dessous pour une explication et plus d'exemples.
Configuration
Notez que l'extension "Lockdown" ne peut être utilisée que pour restreindre l'accès, et non pour l'accorder. Si l'accès est refusé par un paramètre intégré de MediaWiki, il ne peut pas être autorisé en utilisant l'extension de verrouillage.
$wgSpecialPageLockdown
$wgSpecialPageLockdown
vous permet de spécifier pour chaque page spéciale quels groupes d'utilisateurs y ont accès.
Par exemple, pour limiter l'utilisation de Special:Export aux utilisateurs connectés, utilisez ceci dans LocalSettings.php
:
$wgSpecialPageLockdown['Export'] = [ 'user' ];
Notez que certaines pages spéciales "nativement" nécessitent une autorisation spécifique.
Par exemple, Special:MovePage, qui peut être utilisé pour déplacer des pages, nécessite la permission de "move
" (accordée uniquement aux utilisateurs connectés par défaut).
Cette restriction ne peut pas être remplacée à l'aide de l'extension Verrouillage.
Certains titres de pages spéciales ne sont pas mis en majuscules comme ils apparaissent sur le wiki. Par exemple, Special:RecentChanges est Recentchanges en interne, donc vous devez le restreindre :
$wgSpecialPageLockdown['Recentchanges'] = [ 'user' ];
Une liste complète des titres des pages spéciales est disponible dans le fichier MessagesEn.php (tableau $specialPageAliases
) ou vous pouvez aussi utiliser le module API "siteinfo" comme par exemple /api.php?action=query&meta=siteinfo&siprop=specialpagealiases de votre wiki.
$wgActionLockdown
$wgActionLockdown
vous permet de spécifier pour chaque action le groupe d'utilisateurs qui peut y accéder.
Par exemple, pour limiter l'utilisation de la page d'historique aux utilisateurs connectés, utilisez ceci dans 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.
Gestion des groupes
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.
Mesures supplémentaires
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:
Problèmes connus
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.
Voir aussi
- 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
Cette extension est incluse dans les fermes de wikis ou les hôtes suivants et / ou les paquets : Cette liste ne fait pas autorité. Certaines fermes de wikis ou hôtes et / ou paquets peuvent contenir cette extension même s'ils ne sont pas listés ici. Vérifiez toujours cela avec votre ferme de wikis ou votre hôte ou votre paquet avant de confirmer. |