扩展:Lockdown

**MediaWiki扩展手册**
Lockdown; 发行状态：稳定版
实现	用户权限
描述	实现按命名空间的用户组权限
作者	Daniel Kinzler (Duesentrieb留言)
MediaWiki	1.31+
PHP	5.5+
	参数 $wgActionLockdown; $wgNamespacePermissionLockdown; $wgSpecialPageLockdown;
	使用的函数钩 MediaWikiPerformAction; SearchGetNearMatchComplete; SearchableNamespaces; getUserPermissionsErrors;
许可证	GNU General Public License 2.0 or later
下載	下載扩展 ; Git [?]: 浏览存储库 (Phabricator · GitHub); Gerrit代码复核; Git提交日誌; 下載原始碼（tarball壓縮）; ; README
	前往translatewiki.net翻譯Lockdown扩展
問題	开启的任务 · 报告错误

This page is a translated version of the page Extension:Lockdown and the translation is 100% complete.

Lockdown擴展實現一個方式設定用戶組訪向指定命名空間及特殊頁面。这提供了相较默认的$wgGroupPermissions 和$wgNamespaceProtection 设置而言粒度更细的权限控制模型。

以下有关MediaWiki默认使用的权限控制模型的页面可能有助于理解以下说明：

安装

下载文件，并解压Lockdown文件夹到extensions/目录中。
开发者和代码贡献人员应改从Git安装此扩展，输入：
```
cd extensions/
git clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Lockdown
```
請新增下列代码到您的LocalSettings.php 文件的底部：
```
wfLoadExtension( 'Lockdown' );
```
按需求配置
完成 – 請导航至您的wiki上的Special:Version，以验证此扩展已成功安装。

示例

要使用Lockdown来：

防止用户在未登录（即不是注册用户）的情况下使用Special:Export
將專案命名空間的編輯權限收窄到已登入的使用者（註冊使用者）

您可以这样做：

$wgSpecialPageLockdown['Export'] = [ 'user' ];
$wgNamespacePermissionLockdown[NS_PROJECT]['edit'] = [ 'user' ];

参见下文解释和更多示例。

配置

请注意Lockdown扩展只能用于收紧权限，不能用于赋予权限。如果MediaWiki内置设置阻止了部分操作，Lockdown扩展并不能使之取消。

$wgSpecialPageLockdown

$wgSpecialPageLockdown可以指定每个特殊页面所对应的能够使用其的用户组。比如，要将Special:Export限制为只有已登录用户可以使用，在LocalSettings.php中编写：

$wgSpecialPageLockdown['Export'] = [ 'user' ];

注意部分特殊页面本身就要求特定的权限。比如说，Special:MovePage，可以用于移动页面，就需要“move”权限（默认仅已登录用户拥有）。此类限制无法使用Lockdown扩展覆盖。

一些特殊页面的实际标题并不像在wiki上显示的那样大写。比如说。Recentchanges在软件内部是Special:RecentChanges，所以要限制此页面需要编写：

$wgSpecialPageLockdown['Recentchanges'] = [ 'user' ];

特殊页面标题的完整列表参见“MessagesEn.php”文件（的$specialPageAliases数组），或者也可以使用“siteinfo”这一API模块，例如在您的站点上可以通过/api.php?action=query&meta=siteinfo&siprop=specialpagealiases使用。

$wgActionLockdown

$wgActionLockdown可以指定每种操作所对应的能够使用其的用户组。比如，要将历史记录页面限制为只有已登录用户可以使用，在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;

A user who has both read and move permissions for a page can move it to a namespace readable by them but not by others. This can effectively hide the page from other users. Note that move permission alone is not sufficient — users must also be able to view the source page in order to move it.

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

$wgActionLockdownis 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.

管理用户组

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.

附加措施

Images and other uploaded files

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:

參見

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
DisableSpecialPages – Allows making a special page unavailable
CrawlerProtection – Blocks anonymous users from taking actions and accessing special pages most frequently abused by AI crawler bots

此扩展在以下wiki农场/托管网站和/或软件包中提供：