Manual:Preventing access/ja

MediaWikiはページの閲覧および編集するための利用者の機能を制限する、多くの機能を持っている. 編集権限は非常に細かくなっていて、ページレベルであり、多くの便利な自動的な方法で適用される. しかしながら、MediaWikiは企業環境、グループコラボレーションの組織化、あるいは細かなアクセスコントロールが必要なその他の場合にむけてデザインされていないことに留意すること. もしもそれが期待しているものであれば、大規模な修正なしにMediaWikiは期待したとおりに動作しないことが分かるだろう. このページはマニュアルページで、関連するものにリンクが提供されていたとしても、特定の拡張を明示的に扱うものでないことに注意.

ここでのほとんどの変更はLocalSettings.phpへの変更を必要とする. 関連しない命令無しで、任意のコードの断片を影響させるために追加しなければならない. もしも、 LocalSettingsにアクセスできないならば、その多くが実現できない. ファイルはPHPであるが、心配することはない. 1行又は複数行のファイルへの追加は、以下の簡単な手順で行なう:


 * 1) もしも、ファイルの終わりに  があるならば、それを取り去る. それは不必要で邪魔になる.
 * 2) ファイルの末尾に適当なエディタを使って行を追加する. その周りに空白行があっても気にしないこと. バイトオーダマーク(BOM)を追加し、ゴミをまき散らしてしまうため、Windowsのメモ帳は使わないこと. 一般的なBOMの兆候は何もないページとすでに送ったヘッダについてのエラーを含む. BOMを取り去るために、hex editorを使って編集しなければならない.

LocalSettings.phpに付いての詳細な情報は、Manual:LocalSettings.phpを参照. $wgGroupPermissionsページは特に有用である;そこで与えられている一般的なパターンにカスタマイズするところを読むこと.

1.5以前

 * 訳注 1.5より前なので未翻訳

$wgWhitelistAccount = array ( "user" => 0, "sysop" => 1, "developer" => 1 );
 * 1) Prevent new user registrations except by sysops

or

$wgWhitelistAccount = array ( "user" => 0, "sysop" => 0, "developer" => 0 );
 * 1) Prevent new user registrations by anyone

1.5以降
$wgGroupPermissions['*']['createaccount'] = false;
 * 1) 管理者による設定以外で新しい利用者の登録を制限する

新しい利用者は管理者によって以下の方法で引き続き作成できる:


 * 1) 管理者としてログインし、 Special:Userlogin にいく.
 * 2) アカウント作成フォームを出すために"アカウントの作成"をクリックする.
 * 3) 利用者名と、電子メールアドレスを入力し、"メールで送信"ボタンをクリックする.
 * 4) アカウントは指定されたメールアドレスにランダムなパスワード付きでおる羅レ手作成される.

非利用者がログインしようとしたときに表示されるテキストは適した形に修正できる. これは、管理者としてログインしたときに MediaWiki:Nosuchuser で行なうことが出来る. フォーマットが無視され、テキストがその通りに描画されるため、特別な形式を使わないで、平文テキストを使うこと.

管理者でもアカウントを作成できないようにするためには:

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

全てのページの編集制限
利用者は引き続きそれらの変更と共にページを読むことが出来、Special:Export/Article nameかその他の方法(bug 1859を参照)を使うことによってソースを閲覧できる.

1.5以前
$wgWhitelistEdit = true;
 * 1) Disable anonymous editing

1.5以降
$wgGroupPermissions['*']['edit'] = false;
 * 1) IPユーザの編集の無効化

$wgGroupPermissions['*']['edit'] = $wgGroupPermissions['user']['edit'] = false; $wgGroupPermissions['sysop']['edit'] = true;
 * 1) 非管理者の編集の無効化

$wgGroupPermissions['*']['edit'] = $wgGroupPermissions['user']['edit'] = $wgGroupPermissions['sysop']['edit'] = false;
 * 1) すべての人の編集の無効化

1.10以前
1.10以前のコアソフトウェア中ではこの機能は提供されていない. meta:User:PyneJ/Hacks/PageWhiteListのようにハックする必要がある.

1.10以降
MediaWiki 1.10中では、$wgNamespaceProtection変数を使うことで全ての名前空間に対して制限をかけられる. 例:

$wgNamespaceProtection[NS_PROJECT] = array( 'autoconfirmed' );
 * 1) 自動的に認証された利用者のみプロジェクト名前空間を編集可能にする

$wgNamespaceProtection[NS_MAIN]    = $wgNamespaceProtection[NS_USER]  = $wgNamespaceProtection[NS_PROJECT] = $wgNamespaceProtection[NS_IMAGE] = $wgNamespaceProtection[NS_TEMPLATE] = $wgNamespaceProtection[NS_HELP] = $wgNamespaceProtection[NS_CATEGORY] = array( 'emailconfirmed' );
 * 1) 電子メールアドレスで認証されるまで非会話ページ以外の編集を許可しない
 * 2) (はじめるために電子メールで認証されていない利用者から編集を許可することと、
 * 3) 固有の名前空間がないことを仮定している)

$wgNamespaceProtection[NS_POLICY] = array( 'block' );
 * 1) 管理者のみ"Policy"名前空間の編集を許可する

最後の場合、固有の名前空間が存在し、その が名前空間番号と等しい定数として定義していることを仮定する. Manual:Using custom namespacesを参照.

ある特定のページの編集制限
protection機能を使う. 既定値では、任意の管理者は、ページを保護できるが、他の管理者はそれを編集できる. 1.9とそれ以降では、既定値では、ページも保護でき、"自動的に認証された"利用者のみ(構成期限より古いアカウントと共に)は編集できる.

これは構成ファイルの編集は不要である.

ある特定のページの部分を保護する
はじめに編集不可能なエッセイを持つ"Brilliant prose"をあなたのページに持ちたいと共に、以下のような編集可能なコメントがあると考える. (これはblogソフトウェアのようなものではない、MediaWikiの間違った使い方であるが、簡単な例として考えることとする) ページは下記のように見える: Blah blah blah magic I am awesome blah blah blah

Comments
[ Add a comment]

ここで、 "Brilliant prose/comments" は保護されていないページで、"Brilliant prose"それ自身は保護された(保護についてはこの前の節を参照)ページである. 次に、commentsページはessayページ中に含まれ(Help:Templates参照)、他の人は、編集可能なcommentsページを編集することによってコメントを追加することが出来る. 任意の他のセクションは管理者のみか、任意のほごされたページを編集可能なグループのみ可能である.

これは構成ファイルの編集は不要である.

Restrict editing of all but a few pages
It is not really possible 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'll need to find a third-party hack to allow you to do this. (If you do, please add a link in this section!)

Restrict editing for certain IP ranges
Schools and other institutions may want to block all edits not from a few specified IP address ranges. To do so, all other ranges must be blocked. The only way to do this at present without modifying the code is to go to Special:Blockip and systematically block every one of the 65,536 CIDR Class B 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.

Alternatively, it would be possible to hack the code to get it to do this more seamlessly, but that may or may not work indefinitely.

Restrict editing by a particular user
Use the user blocking functionality to deprive a user of all edit access. There is no way in the core software to restrict or allow particular users to edit particular pages, except by changing their usergroup.

Restrict page creation
$wgGroupPermissions['*']['createpage'] = false;
 * 1) Anonymous users can't create pages

$wgGroupPermissions['*'           ]['createpage'] = $wgGroupPermissions['user'        ]['createpage'] = false; $wgGroupPermissions['autoconfirmed']['createpage'] = true; $wgAutoConfirmAge = 86400 * 4; # Four days times 86400 seconds/day
 * 1) Only users with accounts four days old or older can create pages
 * 2) (like Wikipedia!).  Requires MW 1.6 or higher.

Restrict viewing of all pages
if you want anonymous users to be unable to view the wiki, you should not allow them to edit any page (see 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 in 1.10 by using $wgNonincludableNamespaces, but that may not have been extensively tested.

This method is probably best combined with above, unless you want any visitor to be able to view the wiki after creating an account.

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:Image Authorisation, 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.

Pre-1.5
If you want anonymous users not to be able to read or edit your MediaWiki, add this line to your LocalSettings.php:

$wgWhitelistRead = array( "Main Page", "Special:Userlogin", "Wikipedia:Help" );
 * 1) Pages anonymous (not-logged-in) users may see

This way anonymous users can only see the Main Page, the user login page and the help page. Caution: if your MediaWiki is in a language different than English, you need to translate the titles in the array. For instance, in Spanish the line will look like this one:

$wgWhitelistRead = array ("Portada", "Especial:Userlogin", "MiWiki:Ayuda");

For more esoteric languages, for which your editor and PHP parser might be in disagreement over file encoding, you could use the PHP urldecode to input the page names. For example in Hebrew you could use:

$wgWhitelistRead = array(    # "Special":Userlogin (in Hebrew)                         urldecode("%D7%9E%D7%99%D7%95%D7%97%D7%93:Userlogin"),     # "MainPage" in Hebrew     urldecode("%D7%A2%D7%9E%D7%95%D7%93_%D7%A8%D7%90%D7%A9%D7%99") ) ;

Also in some non-esoteric languages you might need to encode the special characters, like ő.

1.5 upwards
$wgGroupPermissions['*']['read'] = false;
 * 1) Disable reading by anonymous users

$wgWhitelistRead = array( "Main Page", "Special:Userlogin", "-", "MediaWiki:Monobook.css" );
 * 1) But allow them to read the Main Page, login page, and JS/CSS pages
 * 1) Same as previous, but for French (be careful of encoding!)
 * 2) $wgWhitelistRead = array( "Page Principale", "Special:Userlogin", utf8_encode('Aide en français'));

The  setting allows users to view the main page and log in. Without this line, no one can log in. 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" in the WhitelistRead.

To allow access to maintenance scripts run on the command line, this might have to be added to LocalSettings.php: if ($wgCommandLineMode) { $wgGroupPermissions['*']['read'] = true; }

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.

Restrict viewing of just some pages
To prevent anyone but sysops from viewing a page, it can simply be deleted. To prevent even sysops from viewing it, it can be removed more permanently with the Oversight extension. To completely destroy the text of the page, it can be manually removed from the database. In any case, the page cannot be edited while in this state, and for most purposes no longer exists.

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.
 * 2) 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. (See 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 two basic possibilities:


 * 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.
 * 2) 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.  One hack for this is the hidden namespaces patch; a number of others are listed in Category:Page Access Control Extensions.  Read about security issues with authorization extensions if you plan to use one of those.

Other restrictions
You may want to have pages editable only by their creator, or ban viewing of history, or any of a number of other things. None of these are supported in MediaWiki. If you need more fine-grained permissions, see the section for links to other wiki packages that are designed for this, as well as hacks that attempt to contort MediaWiki into something it's not designed to be but may work anyway.