Manual:アクセス制限

This page is a translated version of the page Manual:Preventing access and the translation is 26% complete.
Other languages:
Deutsch • ‎English • ‎dansk • ‎español • ‎français • ‎čeština • ‎русский • ‎українська • ‎中文 • ‎日本語

利用者権限の詳細情報は、Manual:利用者権限 を参照してください。 このページではアクセス権の制限に役立つ事例を提供します。

ほとんどの事例は MediaWiki 設定ファイル LocalSettings.php の変更を伴います。 効力を発揮させるには、LocalSettings.php に追加するコードのスニペットには説明を添えないでください。 ファイルにさらに1、2行を追加したい場合は、以下の手順に従います。

  1. ファイル末尾に ?> が記述されている場合は、除去。 不用であり、残しておくと状況によっては障害の原因になるため。
  2. テキストエディタを用いて、ファイル末尾に追加する行を加筆する。 追加部分の上部もしくは下部に空行があっても問題はありません。 ただしWindows Notepad は使えません。自動的に「バイト順マーク」 (BOM) を追加してしまい、ファイルの正確な読み取りを阻害する場合があるからです。 BOM 障害の典型例としてページの白紙化、すでに送信済みのヘッダ行のエラーなどがあげられます。 BOM の削除作業には、ファイル編集にバイナリエディタを使う必要があります。 Windows ワードパッドNotepad++ならほぼ問題ありません。 BOM 除去には Vimというテキストエディタでファイルを開き、「:set nobomb」と入力してから保存するという方法もあります。 Mac 利用者には TextEdit でもこの作業が可能です。

LocalSettings.phpの編集の詳細は、Manual:LocalSettings.php をご参照ください。

Simple private wiki

For the common use case of "a private wiki, for oneself and approved others", you need to:

警告 警告: See the warnings in the sections below; this is simple "general use" code, and may or may not match your requirements.
# Disable reading by anonymous users
$wgGroupPermissions['*']['read'] = false;

# Disable anonymous editing
$wgGroupPermissions['*']['edit'] = false;

# Prevent new user registrations except by sysops
$wgGroupPermissions['*']['createaccount'] = false;

Depending on what extensions you have installed, you may want to whitelist more pages. For example if you are using the Extension:ConfirmAccount extension, you probably want Special:RequestAccount whitelisted. If the content language of your wiki is not English, you may have to use the translated name of the special pages in question.

Restrict account creation

To restrict account creation, you need to edit LocalSettings.php in the root path of your MediaWiki installation.

# Prevent new user registrations except by sysops
$wgGroupPermissions['*']['createaccount'] = false;
You can use the ConfirmAccount extension if you want to set up an account confirmation queue. (If not you may still proceed as follows.)
New users will still be able to be created by sysops, in the following manner:
  1. Go to Special:Userlogin, when logged in as a sysop.
  1. Click on "Create an account" link to get to the account creation form.
  1. Enter a username and an email address, and click the "by email" button.

Note you need $wgEnableEmail=true or else the sysop must pick a password and send it to the user.

  1. The account will be created with a random password which is then emailed to the given address (as with the "forgot password" feature).

The user will be requested to change password at first login; when they do this, the email address will also be marked as confirmed.

  1. When you click the "create account" button instead, you have to manually send the user their password. If you've set $wgMinimalPasswordLength=0 (default configuration up to version 1.15) and you've left the password field blank, the user will be emailed an email address confirmation request but will be unable to access Special:Confirmemail to perform the confirmation. Instead, the user will get an error (unless you've added it to $wgWhitelistRead ); the user will be able to login with a blank password and then confirm email, but their password will not have been reset (it will have to be reset manually).

It may be appropriate to edit the text displayed when a non-user attempts to log in. This can be done at MediaWiki:Nosuchuser, when logged in as a sysop. Use plain text without any special formatting, as the formatting is ignored and the text is literally rendered. (Might have changed, see bug 12952).

You may also modify the contents of the email sent to new users by editing the page MediaWiki:Createaccount-text.

To prevent even sysops from creating accounts:

# Prevent new user registrations by anyone
$wgGroupPermissions['*']['createaccount'] = false;
$wgGroupPermissions['sysop']['createaccount'] = false;

To add a message on top of the login form, modify MediaWiki:Loginprompt.

Restrict editing

Restrict editing of all pages

Users will still be able to read pages with these modifications, and they can view the source by using Special:Export/Article name or other methods. bug 1859 も参照してください。

Help:User rights および Manual:$wgGroupPermissions を参照してください。 If you use Extension:AbuseFilter , any wiki admin can also put various restrictions in place.

Some examples of how to protect all pages from editing (not reading) by certain classes of users:

Restrict anonymous editing

Requires that a user be registered before they can edit.

$wgGroupPermissions['*']['edit'] = false;

Restrict editing by all non-sysop users

Requires that a user be a member of the administrators (sysop) usergroup.

$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['user']['edit'] = false;
$wgGroupPermissions['sysop']['edit'] = true;

Restrict editing by absolutely everyone

$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['user']['edit'] = false;
$wgGroupPermissions['sysop']['edit'] = false;

Restrict editing of an entire namespace

MediaWiki バージョン:
1.10

Starting from MediaWiki version 1.10, it is possible to protect entire namespaces using the $wgNamespaceProtection variable. 例:

# Only allow autoconfirmed users to edit Project namespace
$wgNamespaceProtection[NS_PROJECT] = array( 'autoconfirmed' );

# Don't allow anyone to edit non-talk pages until they've confirmed their
# email address (assuming we have no custom namespaces and allow edits
# from non-emailconfirmed users to start with)
# Note for 1.13: emailconfirmed group and right were removed from default
# setup, if you want to use it, you'll have to re-enable it manually
$wgNamespaceProtection[NS_MAIN]     = $wgNamespaceProtection[NS_USER]  =
$wgNamespaceProtection[NS_PROJECT]  = $wgNamespaceProtection[NS_IMAGE] =
$wgNamespaceProtection[NS_TEMPLATE] = $wgNamespaceProtection[NS_HELP]  =
$wgNamespaceProtection[NS_CATEGORY] = array( 'emailconfirmed' );

# Only allow sysops to edit "Policy" namespace
$wgGroupPermissions['sysop']['editpolicy'] = true;
$wgNamespaceProtection[NS_POLICY] = array( 'editpolicy' );

Note that in the last case it's assumed that a custom namespace exists and that NS_POLICY is a defined constant equal to the namespace number. See Manual:Using custom namespaces and Manual:Namespace_constants for a list of MediaWiki's core namespaces.

Restrict editing of certain specific pages

Use the Protect feature. By default, any sysop can protect pages so only other sysops can edit them. In 1.9 and higher, by default they can also protect pages so only "autoconfirmed" users (with accounts older than a configured period) can edit them. This does not require editing configuration files.

If you want to restrict editing to groups with specific permissions, edit $wgRestrictionLevels . To prevent actions other than edit and move, use $wgRestrictionTypes .

Restrict editing of all but a few pages

To impose a blanket restriction on editing for all pages, but allow a few (such as sandboxes, join request pages, etc.) to be more generously editable, you can use the EditSubpages extension. This may not fit too often, but you could also use the Restrict editing of certain specific pages method mentioned above, with all name spaces protected, and only a special one editable by everyone which has all the pages you want editable.

Restrict editing for certain IP address ranges

Schools and other institutions may want to block all edits not from a few specified IP address ranges. To do so, see Manual:ブロックとブロック解除 . The only way to do this at present without modifying the code is to go to Special:Blockip and systematically rangeblock every one of the address ranges that you don't want to be able to edit. This will work for all future versions of MediaWiki. It will not work on a per-namespace basis.

Restrict editing by a particular user

Use the user blocking functionality to deprive a user of all edit access. MediaWiki does not include a possibility to give rights to separate users directly; instead rights are always given to a user group. There is no way in the core software to change permissions of particular users in order to restrict or allow editing particular pages, except by changing their usergroup.

Restrict creating of all pages

Revoking the edit right already prevents affected users from creating new pages and talk pages.
# Anonymous users can't create pages
$wgGroupPermissions['*']['createpage'] = false;

# Only users with accounts four days old or older can create pages
# Requires MW 1.6 or higher.
$wgGroupPermissions['*'            ]['createpage'] = false;
$wgGroupPermissions['user'         ]['createpage'] = false;
$wgGroupPermissions['autoconfirmed']['createpage'] = true;

Restrict creating pages in certain namespaces

There are separate rights for creating talk pages (createtalk) and creating non-talk pages (createpage). If you need per-namespace control finer than that, it is not possible in core MediaWiki, and requires an extension such as Extension:Lockdown .

Restrict access to uploaded files

Manual:画像認証 , img_auth.php , Manual:User rights (read)

If you have enabled the ability to upload files, these will be served directly by the underlying web server. As a result, account-based access to the file is unrestricted by default.

警告 警告: 利用者権限 「読み取り」 (ページの閲覧を許可) を false に設定すると ウィキ (記事、トーク、...) ページのみが保護されますが、アップロードされた ファイル ($wgUploadPath 下位ディレクトリ内の画像、ファイル、文書...) は常に、既定では直接アクセス経由で読み取り可能なままです
画像の閲覧やファイルのダウンロードのアクセスをログイン利用者のみに制限したい場合は、Manual:画像認証 および img_auth.php の各ページの情報を使用してください。

Example for access restriction to uploaded files in the server configuration

If sensitive files are uploaded to an internet-accessible wiki, you may wish to add restrictions on where these can be accessed from. On Apache, if your local network were 10.1.2.*, you could restrict serving files to local addresses with:

  <Location /mediawiki/images>
    Order deny,allow
    Allow from 10.1.2.3
    Deny from all
  </Location>

Restrict viewing

Restrict viewing of all pages

警告 警告: If you want anonymous users to be unable to view the wiki markup/code, you should not allow them to edit any page (see #Restrict editing of all pages above). If they can edit any page, they can use template inclusion to view even pages they can't edit. This may be possible to avoid by using $wgNonincludableNamespaces
警告 警告: This method allows any visitor to view the wiki after creating an account. You may wish to combine it with #Restrict account creation above.
警告 警告: Uploaded images will still be viewable to anyone who knows the image directory's name. Either point $wgUploadPath to the img_auth.php script and follow the instructions in Manual:画像認証 , or use some external method to protect images, like .htaccess.
If anonymous users can't view your page, neither can search engines. Your site will not be indexed on Google.

Add this line to your LocalSettings.php file:

# Disable reading by anonymous users
$wgGroupPermissions['*']['read'] = false;

# But allow them to read e.g., these pages:
$wgWhitelistRead =  [ "Main Page", "Help:Contents" ];

# Allow Jobs to be run
$wgWhitelistRead = [ "Special:RunJobs" ];

The $wgWhitelistRead setting allows users to view the main page. If page names have more than one word, use a space " " between them, not an underscore "_".

In addition to the main page of such a private site, you could give access to the Recentchanges page (if you think that its content isn't private) for feed readers by adding "Special:Recentchanges" to $wgWhitelistRead .

If you need to protect even the sidebar, main page, or login screen for any reason, it's recommended that you use higher-level authentication such as .htpasswd or equivalent.

Although Special:Listusers won't be available, it can be determined if a username is correct from Userlogin errors. You may want to give a common text for MediaWiki:wrongpassword and MediaWiki:nosuchusershort.

いくつかの特定のページの閲覧制限

管理者以外に閲覧をさせないためには、単にページを削除 します。 管理者にも閲覧させない場合は、さらに永久的に削除するためManual:版指定削除 を使います。 特定ページの記述内容を完全に破壊するには、データベースから手動で削除できます。 いずれの場合も、この状態のページは編集ができず、ほとんどの目的に使おうにも、ページが存在していません。

To have a page act normally for some users but be invisible to others, as is possible for instance in most forum software, is a very different matter. MediaWiki is designed for two basic access modes:

  1. Everyone can view every single page on the wiki (with the possible exception of a few special pages).

This is the mode used by Wikipedia and its sister projects.

  1. Anonymous users can only view the Main Page and login page, and cannot edit any page.

This is basically the same as the above, in terms of technical implementation (just an extra check for every page view), which is why it exists. This is the mode of operation used by certain private wikis such as those used by various Wikimedia committees.

If you intend to have different view permissions than that, MediaWiki is not designed for your usage. (bug 1924 を参照してください。) Data is not necessarily clearly delineated by namespace, page name, or other criteria, and there are a lot of leaks you'll have to plug if you want to make it so (see security issues with authorization extensions for a sample). Other wiki software may be more suitable for your purpose. You have been warned. If you must use MediaWiki, there are three basic possibilities:

  1. Set your wiki up private and whitelist specific pages that will be public with $wgWhitelistRead in the LocalSetting.php file.

See the section above.

  1. Set up separate wikis with a shared user database , configure one as viewable and one as unviewable (see above), and make interwiki links between them.
  1. Install a third-party hack or extension.

You will have to reapply it every time you upgrade the software, and it may not be updated immediately when new security fixes or upgrades of MediaWiki are released. Third-party hacks are, of course, not supported by MediaWiki developers, and if you're having problems you shouldn't ask on MediaWiki-l, #mediawiki, or other official support channels. A number of hacks are listed in カテゴリ:ページ固有の利用者権限の拡張機能 . Read about security issues with authorization extensions if you plan to use one of those.

書き出しの制限

関連項目: Manual:Parameters_to_Special:Export

It is not possible to export the contents of a page that cannot be read since r19935.

ログインのリンクをすべてのページから除去

One can remove the login/create account link from the upper right corner of all pages, as users can still go to Special:SpecialPages>Special:UserLogin to login. In LocalSettings.php use (tested with MediaWiki 1.16)

function NoLoginLinkOnMainPage( &$personal_urls ){
    unset( $personal_urls['login'] );
    unset( $personal_urls['anonlogin'] );
    return true;
}
$wgHooks['PersonalUrls'][]='NoLoginLinkOnMainPage';

アカウントの削除

If you want to completely remove access to a user, e.g. on a simple private wiki, it's not possible to simply delete the account (unless no edits have been made ); you can block it, but the user will still be able to read pages. However, using User Merge and Delete extension you can merge the account in another one and delete the former; the original account will then "disappear". If you want to preserve history readability (i.e., to have edits from the user to be still shown under their name), you can create a new account e.g. with username "OriginalUserName (deactivated)" and then merge "OriginalUserName" into the former, or even use Renameuser extension to rename "OriginalUserName" into "AnotherUserName", then create an account under "OriginalUserName" and merge "AnotherUserName" into it: in this manner, "OriginalUserName" will be completely "usurped" (if you've set a non-null password).

MediaWiki 1.16.0 以降は $wgBlockDisablesLogin を true に設定してブロック済み利用者のアクセスと表示を予防できるようになりました。

その他の制限事項

ページ編集をそのページの作者にのみ認める場合、あるいは編集履歴の秘匿ほか、その他の制限をかけたい場合があるとします。 MediaWiki の標準版では、これらを実現する機能はありません。 さらにきめ細かい権限設定が必要な場合は、#関連項目節にあるリンク先から、他のウィキパッケージでこの機能を備えたもの、あるいは MediaWiki を本来の設計趣旨とは外れるけれども、使える形に変えるハッキングを参照できます。

関連項目

興味があれば、ほかにいくつか関連のマニュアルあるいはヘルプページがあります。

他のウィキソフトウェアのほうがMediaWikiよりもきめの細かいアクセス制限を支援する場合があります。

  • MoinMoin
  • TWiki
  • TikiWiki - 機能や権限レベルでアクセス制限の設定が完全にできます。

もっとアクセス制限を向上させたいけれど MediaWiki で実現したい場合、この拡張機能一覧とハッキングでソフトウェアの標準ではできない制限が可能です。 ただしハッキングが古すぎる可能性もあります(バージョン情報を要確認。) 第三者のハッキングでなにか障害が出ても、MediaWiki の公式サポートで質問はできません。