YK: Chapter 8: User registration and management

User registration and management

Registration

By default, user registration in MediaWiki is fairly simple: for users who are not logged in, at the top of each page is either (for MediaWiki 1.20 and up) two links, reading “Create account” and “Log in”, or one link reading “Log in / create account”. It’s a fairly small difference, since each of those two pages links to the other anyway.

If you click on either “Log in” or “Log in / create account”, you’ll see a screen that looks like Figure 8.1.

[]

Figure 8.1 Login screen for a fictional wiki

If you click on the “Create account” link, either from this screen or (if it’s there) from the top of any page, you’ll see something like Figure 8.2.

[]

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, if you’re using MediaWiki 1.22 or later, 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 listing of these extensions here:

https://www.mediawiki.org/wiki/Category:Real_name_display_extensions

If, as an administrator, you want users to fill in more information about themselves when they register, there’s at least one extension that allows that: SemanticSignup, which also requires the Semantic MediaWiki and Semantic Forms extensions. You can read more about SemanticSignup here:

https://www.mediawiki.org/wiki/Extension:SemanticSignup

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.

Usernames

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:

1. < > [ ] | { } / @

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 “123.45.67.89” (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.

[]

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:

https://www.mediawiki.org/wiki/Manual:User_rights

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:

https://www.mediawiki.org/wiki/Extension:ConfirmAccount

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:

https://www.mediawiki.org/wiki/Extension:InviteSignup

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.

OpenID and other login integration systems

OpenID is an exciting technology that aims to solve a chronic issue on the web: the proliferation of user accounts and passwords. The concept is that a user can associate their accounts on websites with a standard "identity provider", like Google, Yahoo! etc.

OpenID was invented in 2005, but it only started to gain real acceptance a few years later, with companies like Google, Microsoft and Yahoo! starting to offer support for it in 2008. It has been seen steadily increasing in usage since then, although it remains a relatively unknown technology. In 2014, a more powerful version was released, called “OpenID Connect”. The software remains in flux, and hopefully, its best days are yet to come.

You can use OpenID on your MediaWiki website, by installing the extension that’s appropriately also called “OpenID”:

https://www.mediawiki.org/wiki/Extension:OpenID

If you install it, users who are not logged in will see an OpenID link at the top of every page ­ next to the "Log in / create account" link will be a link that reads "Log in / create account with OpenID". If they click on that, they will see the interface shown in Figure 8.4.

[]

Figure 8.4 OpenID login/registration screen

This interface allows users to easily create a MediaWiki account that’s associated with an account from one of the 12 OpenID providers whose icons are shown (the bottom set of icons includes sites such as LiveJournal and Flickr). Users just have to click the relevant icon and follow the instructions.

A user who creates an account can choose any username within MediaWiki (provided it’s not taken already) ­ there doesn’t have to be a connection between their username in the OpenID provider system and the one they choose for the wiki.

There are a number of OpenID configurations that one can make, but the most important one is to be able to set OpenID as the only login option; so that users will not see the regular “Log in / create account” link. You can do this by adding the following to LocalSettings.php:

$wgOpenIDOnly = true;

The "OpenID only" setting has a very useful benefit, which is that it seems to stop spammers entirely (provided one also restricts editing to logged-in users).

You can also use the OpenID extension to turn your wiki into an OpenID provider/server, not just an OpenID consumer, but this is very rarely done.

In addition to OpenID, there are other protocols that can be used to allow users to log in using existing accounts, available via different extensions:

The LDAP Authentication extension lets users log in via LDAP accounts:

https://www.mediawiki.org/wiki/Extension:LDAP_Authentication

This is especially helpful for internal wikis that want to make use of an existing LDAP server (most commonly, using Microsoft’s Active Directory) that stores a personnel directory.

The Facebook Open Graph extension lets users register and log in to MediaWiki with their Facebook accounts:

https://www.mediawiki.org/wiki/Extension:Facebook

The TwitterLogin extension lets users register and log in with their Twitter accounts:

https://www.mediawiki.org/wiki/Extension:TwitterLogin

To use this extension, you need to register your site with Twitter as a Twitter app.

The Persona extension lets users log in using Mozilla Persona, which is a generic authentication protocol similar in concept to OpenID:

https://www.mediawiki.org/wiki/Extension:Persona

The OAuth protocol is similar in spirit to OpenID, but differs in some key ways. It’s not yet possible to log in to MediaWiki via OAuth, but there’s a project in place to allow this. You can see its current status here:

https://www.mediawiki.org/wiki/OAuth

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.5 shows the interface viewable at Special:Block.

[]

Figure 8.5 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 “123.45.0.0 ­ 123.45.255.255”.

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:

https://www.mediawiki.org/wiki/Help:Range_blocks

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 - that will show the complete list of blocks that have been made on this 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. Unfortunately, that’s not the case ­ and there’s no “block from reading” or “block from logging in” action, nor does there appear to be an extension to do it. But if you have a closed wiki, and want that ability, adding the following to LocalSettings.php should do the trick:

$wgHooks['UserGetRights'][] = 'blockFromReading';

static function blockFromReading( $user, &$rights ) {

if ( $user->isBlocked() ) {

foreach ( $rights as $i => $right ) {

if ( $right === ’read’ ) {

unset( $rights[$i] );

break;

}

return 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:

http://www.mediawiki.org/wiki/Extension:UserMerge

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.