Manual:Preventing access

MediaWiki has a number of features to restrict users' ability to view and edit pages. Editing permissions are very fine-grained, down to the page level, and can be applied in various useful automated ways. However, keep in mind that MediaWiki is not designed for corporate environments, organization of group collaboration, or other situations where fine-grained access control is needed. If that is what you want, you may find that MediaWiki will not do what you want it do without extensive modification. Note that this page is a manual page and will not explicitly deal with specific extensions, although links will be provided to relevant ones.

Most of the changes here require modifications to LocalSettings.php. Any snippets of code with no accompanying instructions must be added to that file to take effect. If you don't have access to LocalSettings, you won't be able to do most of them. The file is in PHP, but don't worry about that. To add one or more lines to the file, just follow these very simple steps:


 * 1) If there is a   at the end of the file, remove it.  It's not necessary and just gets in the way.
 * 2) Add the line to the bottom of a file, using a good text editor.  It doesn't matter if there are some blank lines around it.  Do not use Windows Notepad, as it may add a BOM and muck up the file.  Typical symptoms of BOMs include white pages and errors about headers already being sent.  To remove a BOM, you'll have to edit the file in a hex editor.

For more information about LocalSettings.php, see Manual:LocalSettings.php. The $wgGroupPermissions page is of particular interest; read that to customize the general patterns given here.

Pre-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 upwards
$wgGroupPermissions['*']['createaccount'] = false;
 * 1) Prevent new user registrations except by sysops

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.
 * 2) Click on "Create an account" to get to the account creation form.
 * 3) Enter a username and an email address, and click the "by email" button.
 * 4) The account will be created with a random password which is then emailed to the given address.

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.

To prevent even sysops from creating accounts:

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

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 (see also bug 1859).

Pre-1.5
$wgWhitelistEdit = true;
 * 1) Disable anonymous editing

1.5 upwards
$wgGroupPermissions['*']['edit'] = false;
 * 1) Disable anonymous editing

$wgGroupPermissions['*']['edit'] = $wgGroupPermissions['user']['edit'] = false; $wgGroupPermissions['sysop']['edit'] = true;
 * 1) Disable editing by all non-sysop users

$wgGroupPermissions['*']['edit'] = $wgGroupPermissions['user']['edit'] = $wgGroupPermissions['sysop']['edit'] = false;
 * 1) Disable editing by absolutely everyone

Pre-1.10
This functionality is not available before 1.10 in the core software. You will have to use a hack, such as meta:User:PyneJ/Hacks/PageWhiteList.

1.10 upwards
In MediaWiki 1.10, it is possible to protect entire namespaces using the $wgNamespaceProtection variable. Examples:

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

$wgNamespaceProtection[NS_MAIN]    = $wgNamespaceProtection[NS_USER]  = $wgNamespaceProtection[NS_PROJECT] = $wgNamespaceProtection[NS_IMAGE] = $wgNamespaceProtection[NS_TEMPLATE] = $wgNamespaceProtection[NS_HELP] = $wgNamespaceProtection[NS_CATEGORY] = array( 'emailconfirmed' );
 * 1) Don't allow anyone to edit non-talk pages until they've confirmed their
 * 2) e-mail address (assuming we have no custom namespaces and allow edits
 * 3) from non-emailconfirmed users to start with)

$wgNamespaceProtection[NS_POLICY] = array( 'block' );
 * 1) Only allow sysops (who are the only ones with the 'block' permission)
 * 2) to edit "Policy" namespace

Note that in the last case it's assumed that a custom namespace exists and that  is a defined constant equal to the namespace number. See Manual:Using custom namespaces.

Using existing permissions to do several new things is not ideal practice. In the final example above, it is usually proper to define an  permission in another area of LocalSettings.php (where $wgGroupPermissions is defined), assign it to sysops, and use   in $wgNamespaceProtection.

Restrict editing of certain specific pages
Use the protection 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.

Restrict editing of parts of certain specific pages
Suppose you want your page "Brilliant prose" to have an uneditable essay at the beginning, and an editable comment section below. (This is probably a bad use for MediaWiki, as opposed to something like blog software, but let's stick with it as a simple example.) The page could look like this: Blah blah blah magic I am awesome blah blah blah

Comments
[ Add a comment]

where "Brilliant prose/comments" is an unprotected page, and "Brilliant prose" itself is protected (see previous section for info on protection). Then the comments page will be included in the essay page (see Help:Templates), and people can add their comments by editing the editable comments page. They will immediately be included on the main essay's page. Edits to any other section are only possible for sysops, or whatever groups can edit appropriately protected pages.

This does not require editing configuration files.

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.