This page is a translated version of the page Extension:Lockdown and the translation is 100% complete.
MediaWiki 拡張機能マニュアル
リリースの状態: 安定
実装 利用者権限
説明 名前空間ごとのグループ権限の実装
作者 Daniel Kinzler (Duesentriebトーク)
MediaWiki 1.31+
PHP 5.5+
ライセンス GNU 一般公衆利用許諾書 2.0 以降
  • $wgActionLockdown
  • $wgNamespacePermissionLockdown
  • $wgSpecialPageLockdown
Quarterly downloads 498 (Ranked 12th)
translatewiki.net で翻訳を利用できる場合は、Lockdown 拡張機能の翻訳にご協力ください
問題点 未解決のタスク · バグを報告

Lockdown拡張機能は、特定の名前空間や特別なページへのアクセスを、指定された利用者グループの集合に制限する方法を実装しています。 これにより、既定の $wgGroupPermissions $wgNamespaceProtection 設定で提供されるセキュリティ モデルよりも、よりきめ細かいセキュリティ モデルが提供されます。

MediaWiki が既定で使用するセキュリティ モデルについての以下のページが、下記の説明を理解するのに役立つでしょう:


  • ダウンロードして、ファイルをextensions/フォルダー内のLockdownという名前のディレクトリ内に配置します。
    Developers and code contributors should install the extension from Git instead, using:cd extensions/
    git clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Lockdown
  • 以下のコードを LocalSettings.php ファイルの末尾に追加します:
    wfLoadExtension( 'Lockdown' );
  • 必要に応じて設定します
  •   完了 – ウィキの「Special:Version」に移動して、拡張機能が正しくインストールされたことを確認します。


  • Special:Export へのアクセスをログイン済み利用者 (登録利用者) のみに制限する
  • プロジェクトの名前空間の編集をログイン利用者(登録利用者)に制限する。


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



Lockdown拡張機能はアクセスを制限するためにのみ使用でき、アクセスを許可するために使用できるわけではないことに注意してください。 MediaWikiの組み込み設定によってアクセスが拒否される場合、Lockdownを使用してアクセスを許可することはできません。


$wgSpecialPageLockdown では、各特別ページに対して、どのユーザーグループがアクセスできるかを指定することができます。 例えば、履歴ページの利用をログイン済み利用者に限定する場合は、Special:Export で以下を使用します:

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

なお、特殊なページの中には、「ネイティブ」に特定の権限が必要なものがあります。 例えば、ページの移動に使用できるSpecial:MovePageは、"move "権限(デフォルトではログインしたユーザーにのみ付与)が必要です。 この制限は、Lockdownを使用して上書きすることはできません。

一部の特殊なページタイトルは、wiki上での表示と異なり、大文字で表示されます。 例えば、Special:RecentChangesは内部的にはRecentchangesなので、それを制限するために必要です。

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

特殊なページタイトルの完全なリストは、"MessagesEn.php" ファイル ($specialPageAliases 配列) で入手できます。あるいは、あなたの wiki で /api.php?action=query&meta=siteinfo&siprop=specialpagealiases などの "siteinfo" API モジュールを使用することもできます。


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

$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:


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.