Working with MediaWiki
2nd ed., HTML version

Chapter 8 User registration and management


Figure 8.1: Login screen for a fictional wiki
The email address field is recommended for all users to fill in, since it allows for notification and messaging. As an administrator, you can require users to enter and confirm an email address before they can read or edit on the wiki, if you want, by using the “emailconfirmed” group (see next section).
There are also various extensions that allow for displaying real names in different formats; you can see a listing of these extensions here:
Another extension, ConfirmAccount, requires potential users to fill in more information about themselves – for the purpose of getting approval to become a user. See here for more detail.


In general, MediaWiki is very flexible about the username users can choose – it can include nearly any Unicode character, including spaces. There are some restrictions, though: usernames of course have to be unique, and they can't contain any of the reserved characters that page names can't contain, plus a few more. Here is the main list of characters not allowed in usernames:
# < > [ ] | { } / @
There are also various control characters, and unusual whitespace characters, which usernames can't contain. And you can't create a username that spoofs a MediaWiki page name with a namespace, like “Help:Contents”, or spoofs an IP address, like “” (the latter is because the IP address is used as an identifier for users who are not logged in).
Also, a username cannot be longer than 40 characters.
Finally, usernames cannot start with a lowercase letter – if you register a username that stars with a lowercase letter, the first letter will get automatically capitalized. That holds true even if lowercase first letters in page names are enabled, using “$wgCapitalLinks = true”.

User groups and permissions

All user-rights management in MediaWiki is done via “groups”, and not for individual users. You can't assign permissions to an individual wiki user – instead, you put users in different groups, with each having its own set of permissions.

Default user groups

By default, there are five defined groups to which users can be added: “sysop”, “bureaucrat”, “interface-admin”, “suppress” and “bot”.
“sysop” is a misnamed group – sysops don't do anything with administering the server on which the wiki resides, as you might think from the name; instead, they simply administer wiki content. “administrator” would be a much more accurate name, and in fact the term “administrator” is how it is referred to in the web interface, but behind the scenes it's still called “sysop”. Sysops/administrators, by default, can perform the main administrative tasks on wikis: deleting pages, "protecting" pages (so that some or all non-sysop users can't edit them), blocking users, etc.
The main right of the “bureaucrat” group, by default, is to be able to assign users to different groups.
The “interface-admin” group, by default, can edit interface-related pages on the wiki such as MediaWiki:Common.css.
The “suppress” group, by default, can do actions related to suppressing (hiding) and deleting unwanted page revisions and log entries.
There are three more implicit groups, which users can't be added to or removed from but simply belong to: “user”, “autoconfirmed” and “emailconfirmed”. Once a user registers with a username, they're defined as a “user”; once they've been in the system for long enough and have made enough edits (both values are settable) they're also in “autoconfirmed”, and once they confirm an email address, they're in “emailconfirmed” as well.
When a wiki is first set up, an initial account is created: by default it's called “WikiSysop”. This account initially belongs to both the “sysops” and “bureaucrats” group, so anyone logged in as WikiSysop can make other users administrators and bureaucrats as well, thus setting up the whole user structure.
What if you accidentally lose the password for this first user account (whether it's called WikiSysop or anything else), though? Hope is not lost: you can use the “createAndPromote.php” script, in MediaWiki's maintenance/ directory, which lets you create new users – and more importantly, add any new user, new or existing, to any user group. Here is how to call it in order to create an administrator account, if you can't log in to the “WikiSysop” account:
php maintenance/createAndPromote.php username password –sysop –bureaucrat
Figure 8.3: Special:UserRights page

Setting permissions

$wgGroupPermissions['group name']['action name'] = true/false;
For instance, by default, only sysops/administrators can delete pages. The action for deleting pages is called, as you would expect, 'delete'. So, to allow bureaucrats to also delete pages, you would need to add the following line to LocalSettings.php:
$wgGroupPermissions['bureaucrat']['delete'] = true;

Creating new groups

And how do you add a new group? That's actually very simple: as soon as a group is referred to in LocalSettings.php, within a “$wgGroupPermissions” call, it gets defined within the system if it wasn't defined already. So, for instance, suppose you want to create a new user group, “blocker”, whose only special rights are the ability to block and unblock users. You would just have to add the following to LocalSettings.php:
$wgGroupPermissions['blocker']['block'] = true;
When they're first created, new groups don't have any members. So, once you created the “blocker” group, you would presumably use the page Special:UserRights to start adding users to that group.

Common permissions settings

$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['user']['edit'] = true;
$wgGroupPermissions['*']['read'] = false;
$wgGroupPermissions['user']['read'] = true;
Another somewhat-common setting is to turn off user registration on the wiki, so that only administrators can add new users. This is again accomplished with just two lines:
$wgGroupPermissions['*']['createaccount'] = false;
$wgGroupPermissions['sysop']['createaccount'] = true;
There are actually dozens of settable MediaWiki permissions, defined within both core MediaWiki and many of its extensions. Some of these are covered in this book, but a complete list of all MediaWiki permissions can be found at:
Restricting the viewing and editing of specific pages or sections in the wiki is covered on here.

Creating user accounts

This section does not cover standard MediaWiki registration, but rather existing users creating additional user accounts. For public wikis in which anyone can sign up, or private wikis in which anyone within the relevant network can sign up, that's not a very important feature – if someone wants an account on the system, they can just create one themselves. However, there are cases when you want closed registration – where only existing users, or only administrators, can create an account. The way to create an additional account, when you're logged in, is to simply go to the “Create an account” page. If you're logged in, that page is not linked from the top of pages, but you can reach it by going to Special:UserLogin and clicking on “create an account” – or going directly to the URL “Special:UserLogin?type=signup”. And if you have the Admin Links extension installed (see here), this URL is included directly in that page of links.
The permissions around creating user accounts are governed by the 'createaccount' right. So, for instance, to allow only administrators to create new user accounts, you would add the following to LocalSettings.php:
$wgGroupPermissions['*']['createaccount'] = false;
$wgGroupPermissions['sysop']['createaccount'] = true;
InviteSignup is somewhat the mirror image of ConfirmAccount: they both require both a wiki user and an outsider to agree to the outsider's joining, but with ConfirmAccount the process is initiated by the potential new user, while with InviteSignup it's initiated by the existing user.

Login integration systems

You may want to have users log in to MediaWiki via an existing account from another system, eliminating the need to create a new account on the wiki. Ideally, user permissions from the other system can carry over into this one (where applicable), so that a user registered as an administrator will also get administrator privileges on the wiki – and a user without sufficient privileges may even be prohibited from logging in. Making use of outside accounts is usually referred to as “authentication”, while carrying over permissions is usually referred to as “authorization”.
The current status of MediaWiki authentication is mixed: you can enable SSO in conjunction with Google, Wikipedia, Facebook and Microsoft, as well as protocols like LDAP and SAML, but some of these are better supported than others.
PluggableAuth also supports two options for authorization:
You can read more about PluggableAuth here:

Blocking and deleting users

Administrators can block other users from editing, which is extremely useful when dealing with spammers, vandals, and (to a more limited extent) people who make too many poor edits. Blocking is governed by the 'block' permission.
Figure 8.4: Special:Block page
You can specify either a username or an IP address to block; if the user in question is making edits without being logged in, then you will of course have to specify their IP address. In reality, it shouldn't matter which you do, as long as you keep the “Automatically block the last IP address used by this user...” checkbox checked (which you should, assuming that this is a true malicious user and not just someone that you temporarily want to send a message to).
The checkbox defaults are generally good; however, it's usually a good idea to check the last checkbox as well, “Prevent logged-in users from editing from this IP address”. Spammers can sometimes register hundreds of accounts, then wait until months or even years later to attack with them. If you select that checkbox, all those accounts could potentially be neutralized, which would be a big win.
Sometimes, spammers and malicious users can use a whole range of IP addresses, such as any address that starts with “123.45”, or “123.45.67”. (Even if they're always logged in when making edits, you can still find out their IP address if you're an administrator – see here.) If that's the case, blocking individual IP addresses will probably be ineffectual. Thankfully, the Block page also lets you block an entire range of IP addresses, which can end up being a real lifesaver. To do that, you can simply specify a range instead of a single IP address in the “IP address or username” field. For the first example, you could enter “ –”.
For what it's worth, there's a whole syntax you can use for IP range blocks, beyond the simple “a – b” formulation – it's all described here:
The “Expiry” field dictates how long the user will be blocked for – this can always be changed later. With spammers and egregious vandals, the best approach is to block them “Indefinitely”, i.e. forever.
On wikis with closed registration, blocking a user would ideally prevent them from being able to read any of the contents as well. You can enable that – by preventing them from logging in at all – by adding the following line to LocalSettings.php:
$wgBlockDisablesLogin = true;
It lets you merge two user accounts together, with one of the accounts then getting deleted. So to delete a group of accounts, you would need to keep merging them in, one at a time, into a single account – a manual process that may be too slow to run for a large group of accounts.