Manual:Preventing access - MediaWiki

Manual:Preventing access - MediaWiki
Jump to content
From mediawiki.org
Translate this page
Languages:
Bahasa Indonesia
Kadazandusun
català
dansk
italiano
polski
português
svenska
čeština
русский
українська
বাংলা
中文
For help customizing user rights, see
Manual:User rights
This page contains examples useful for restricting access.
For information on how to edit
LocalSettings.php
, see
Manual:LocalSettings.php
Simple private wiki
For the common
use case
of "a private wiki, for oneself and approved others", you need to:
Restrict viewing
Restrict editing
Restrict account creation
Warning:
Do not
use the example code without thorough testing and customization. The code provided is basic and incomplete for real-world use. It might not block access in all ways, could cause problems with other extensions, and might accidentally show private information.
# 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:
Go to
Special:Userlogin
, when logged in as a sysop.
Click on
Create account
link to get to the account creation form.
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.
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.
If you click the "create account" button instead, you have to manually send the user their password.
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.
See also
bug 1859
Fixed
See
Help:User rights
and
$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 version:
1.10
Starting from MediaWiki version 1.10, it is possible to protect entire namespaces using the
$wgNamespaceProtection
variable.
Examples:
# Only allow autoconfirmed users to edit Project namespace
$wgNamespaceProtection
NS_PROJECT
array
'autoconfirmed'
);
# 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:Block and unblock
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
Further information:
Manual:Image authorization
img_auth.php
, and
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
Setting the
user right
'read'
to
false
only restricts access to wiki pages (such as articles and talk pages).
Uploaded files (including images, files, docs) under the
$wgUploadPath
subdirectories will
always
remain publicly accessible via direct URL access by default.
To restrict access to uploaded files, refer to the instructions in
Manual:Image authorization
and
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:

Order deny,allow
Allow from 10.1.2.3
Deny from all

Restrict viewing
Restrict viewing of all pages
Warning:
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
Warning:
This method allows any visitor to view the wiki after creating an account. You may wish to combine it with
§ Restrict account creation
above.
Warning:
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 authorization
, or use some external method to protect images, like
.htaccess
Warning:
Wiki pages like
MediaWiki:Common.css
and
MediaWiki:Gadget-foo.css
may be part of a public ResourceLoader module, and thus can have their source code exposed through
load.php
. Turn off
$wgUseSiteJs
and
$wgUseSiteCss
to disable this functionality.
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"
];
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.
Warning:
If you are running a
private wiki
it is required that you upgrade
to MediaWiki version
1.39.13
1.43.2
1.44.0
or a later, to protect your wiki. A security vulnerability (
CVE-2025-6590
) affects older versions, allowing any user to view all pages on private wikis. There is no workaround available.
[1]
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
Restrict viewing of certain specific pages
MediaWiki was not designed to support per-page or partial-page access restrictions.
If you require this level of control, you are strongly advised to use a
content management system
that supports it natively.
Patches or third-party extensions claiming to provide access control, when in use with MediaWiki, may not work in all cases, potentially exposing confidential data.
Use them at your own risk.
Neither the MediaWiki developers nor the Wikimedia Foundation are responsible for any data leaks that may result.
This message is added to all extensions of this nature and may not reflect the actual security status of this extension.
For more information, see
Security issues with authorization extensions
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 using
Manual:RevisionDelete
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:
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.
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
T3924
Declined
.)
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:
Set your wiki up private and whitelist specific pages that will be public with
$wgWhitelistRead
in the LocalSetting.php file. See the section above.
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.
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
Category:Page specific read access extensions
. Read about
Security issues with authorization extensions
if you plan to use one of those.
Restricting exporting
See also:
Manual:Parameters to Special:Export
It is not possible to export the contents of a page that cannot be read since
r19935
Removing the Login link from all pages
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 log in.
In
LocalSettings.php
use (tested with MediaWiki 1.43.0 LTS):
$wgHooks
'SkinTemplateNavigation::Universal'
][]
function
$skinTemplate
$links
unset
$links
'user-menu'
][
'createaccount'
);
unset
$links
'user-menu'
][
'login'
);
unset
$links
'user-menu'
][
'login-private'
);
unset
$links
'user-menu'
][
'anoncontribs'
);
};
Removing accounts
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 (unless
$wgBlockDisablesLogin
is set).
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 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).
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 features are available in an unhacked version of MediaWiki.
If you need more fine-grained permissions, see the
#See also
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.
See also
There are some related manual/help pages that may be of interest:
Manual:LocalSettings.php
Manual:$wgGroupPermissions
Manual:$wgRestrictionTypes
Manual:$wgRestrictionLevels
Manual:$wgNamespaceProtection
Manual:$wgEmailConfirmToEdit
Manual:$wgNonincludableNamespaces
Manual:User rights
Help:User rights and groups
Other wiki software
may have better support for fine-grained access control than MediaWiki:
MoinMoin
TWiki
TikiWiki
– has fully configuable access control to features and permission levels.
If you want better access control but want to use MediaWiki, this is a list of
extensions
and hacks to allow restrictions not possible in the software proper.
These hacks may be out-of-date (check the version they're for).
Please don't ask in official MediaWiki support channels if something goes wrong with a third-party hack.
Extension:Flagged Revisions
Extension:Moderation
Extension:Approved Revs
Extension:Lockdown
Extension:AuthorProtect
Extension:EditSubpages
– restricts anonymous users from editing most pages
Extension:NSFileRepo
Retrieved from "
Categories
Page specific read access extensions
MediaWiki configuration
Configure
Permission
Namespace
Manual
Preventing access
Add topic