Working with MediaWiki
2nd ed., HTML version

8 User registration and management


By default, user registration in MediaWiki is fairly simple: for users who are not logged in, at the top of each page are two links, reading "Create account" and "Log in". If you click on "Log in", you'll see a screen that looks like Figure 8.1. And if you click on "Create account", either from this screen or (if it's there) from the top of any page, you'll see something like Figure 8.2.
Login page.png
Figure 8.1 Login screen for a fictional wiki
Create account page.png
Figure 8.2 "Create account" screen for a fictional wiki
There is no demographic or questionnaire information solicited; just the essential fields of username and password, plus optional fields for email address and real name, and a bit of automatic promotional text. And if you have the anti-spam ConfirmEdit extension installed (see here), you will probably also see some form of CAPTCHA there.
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).
What about the "Real name" field? That's not a very important field, but it can be nice to fill in if your username is different from your real name, but you still want people to know what your real name is. Other users can view it if they go to the "action=credits" URL for a specific page (this has to be typed in manually; it's not linked from anywhere). On Wikipedia and other Wikimedia sites, this action is disabled, for privacy reasons. (Most likely the disabling was done using the $wgActions setting.)
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 three defined groups to which users can be added: "sysop", "bureaucrat" 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 "bot" group is meant to be reserved for user accounts that are actually automated scripts, which perform various actions. Bots are prevalent on Wikipedia, but are rare on most smaller wikis. You can read about bots here.
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.
The page Special:UserRights is the page with which bureaucrats (by default) can change any user's group memberships. Figure 8.3 shows one example of how it could appear.
User Rights page.png
Figure 8.3 Special:UserRights page

Setting permissions

How are the permissions of each user group set? That's done through the LocalSettings.php file, and the variable $wgGroupPermissions. Every permission that can be set has its own name, which is usually the name of the action that would be performed. To set whether the a certain user group can perform a certain action, the general form in LocalSettings.php is:
$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

In addition to specific group names, you can use the value '*' to refer to everyone, including non-logged-in users, if the wiki has them. This comes in handy when removing rights that by default are available to everyone. So if you want to make editing of pages available only to logged-in users (a common setting), you can just add the following two lines:
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['user']['edit'] = true;
Similarly, to disallow viewing of the site by anyone not logged in, you would add:
$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 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;
If you did that, you should presumably include at least an email address on the wiki, for people to write to to request an account – this makes sense whether the wiki is public or internal. But the best approach is probably to use the ConfirmAccount extension, which provides a form to let potential new users request a user account. As part of the request, they can supply some information about themselves. When a request happens, an administrator can be notified by email; once an admin approves the request (from within the wiki), the new account is created automatically. The whole process works quite well in practice. You can find download and installation information about ConfirmAccount at its homepage:
Another extension which can be used either instead of or in addition to ConfirmAccount is InviteSignup, which lets administrators, and potentially regular users as well, send out invites to other people to join the wiki, using just their email address. Invitees can then go to the site and automatically sign up, choosing their own username and password:
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 authorization part tends to be more important for private, corporate wikis, where all the potential users are already registered in some other system, like an LDAP server. For public wikis, the goal is usually simply to allow users to register with their account from a widely-used website such as Google or Facebook; and from that point on, to be able to log in automatically if they are already logged in to this other system, in what is known as a single sign-on (SSO) process.
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.
The current best approach to login integration with other systems is the PluggableAuth extension, where "Auth" stands for both "authentication" and "authorization". It lets you configure both aspects, so you can have authentication and authorization coming from different systems. For the authentication, you can choose between five extensions that work with PluggableAuth:
PluggableAuth also supports two options for authorization:
You can read more about PluggableAuth here:
Outside of PluggableAuth, there are a few other options:
Finally, there is the combination of the OAuth and OAuthAuthentication extensions:

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.
Blocking is done at the page Special:Block, which you can go to directly, although for administrators it's also linked to from each row in both the RecentChanges page and in history pages. Figure 8.4 shows the interface viewable at Special:Block.
Block interface.png
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.
Conversely, if you want to unblock a user, IP address or IP range, you should go to the page Special:BlockList - it will show the complete list of blocks that have been made on the wiki, in chronological order; with links to undo any of them.
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;
For obviously malevolent user accounts – like when spammers register with lots of accounts in quick succession – it would be great to not just block these accounts but delete them. Unfortunately, there's no extremely easy way to do it. MediaWiki itself doesn't offer the ability to delete accounts at all; for that, you'll need the UserMerge extension:
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.