Extension:ConfirmAccount

The ConfirmAccount extension disables direct account creation and requires the approval of new accounts by a bureaucrat. Direct account creation can still be enabled (if you want Sysops/Bureaucrats to be able to directly make them) by configuring user rights.

The ConfirmEdit extension can be used (in conjunction with the ConfirmAccount extension) in order to use captchas to stop flood requests.

The new user log (now obsolete) extension also works with ConfirmAccount.

Setup

 * Download the latest snapshot of the extension version that matches your Mediawiki install version and extract it to your extensions directory. Select the snapshot for your version of MediaWiki.
 * version =< 1.16: To LocalSettings.php add:


 * version >= 1.17: To LocalSettings.php add:


 * Add the following tables to your MySQL database:

-- (c) Aaron Schulz, 2007 -- Table structure for table `Confirm account` -- Replace /*$wgDBprefix*/ with the proper prefix -- This stores all of our reviews, -- the corresponding tags are stored in the tag table CREATE TABLE IF NOT EXISTS /*_*/account_requests (   acr_id int unsigned NOT NULL auto_increment PRIMARY KEY,    -- Usernames must be unique, must not be in the form of    -- an IP address. _Shouldn't_ allow slashes or case    -- conflicts. Spaces are allowed, and are _not_ converted    -- to underscores like titles. See the User::newFromName for    -- the specific tests that usernames have to pass.    acr_name varchar(255) binary NOT NULL default ,    -- Optional 'real name' to be displayed in credit listings    acr_real_name varchar(255) binary NOT NULL default ,    -- Note: email should be restricted, not public info.    -- Same with passwords.    acr_email tinytext NOT NULL,    -- Initially NULL; when a user's e-mail address has been    -- validated by returning with a mailed token, this is    -- set to the current timestamp.    acr_email_authenticated binary(14) default NULL, -- Randomly generated token created when the e-mail address -- is set and a confirmation test mail sent. acr_email_token binary(32), -- Expiration date for the user_email_token acr_email_token_expires binary(14), -- A little about this user acr_bio mediumblob NOT NULL, -- Private info for reviewers to look at when considering request acr_notes mediumblob NOT NULL, -- Links to recognize/identify this user, CSV, may not be public acr_urls mediumblob NOT NULL, -- IP address acr_ip VARCHAR(255) NULL default '', -- Name of attached file (.pdf,.doc,.txt etc...) acr_filename VARCHAR(255) NULL, acr_storage_key VARCHAR(64) NULL, -- Prospective account access level acr_type tinyint(255) unsigned NOT NULL default 0, -- Areas of interest acr_areas mediumblob NOT NULL, -- Timestamp of account registration. acr_registration char(14) NOT NULL, -- Flag for rejected accounts acr_deleted bool NOT NULL, -- Time of rejection (if rejected) acr_rejected binary(14), -- Time request was put on hold (if held) acr_held binary(14), -- The user who rejected/held it   acr_user int unsigned NOT NULL default 0, -- Reason acr_comment varchar(255) NOT NULL default '' ) /*$wgDBTableOptions*/; CREATE UNIQUE INDEX /*i*/acr_name ON /*_*/account_requests (acr_name);  CREATE UNIQUE INDEX /*i*/acr_email ON /*_*/account_requests (acr_email(255));  CREATE INDEX /*i*/acr_email_token ON /*_*/account_requests (acr_email_token);  CREATE INDEX /*i*/acr_type_del_reg ON /*_*/account_requests (acr_type,acr_deleted,acr_registration);  -- This stores all of credential information  -- When accounts are confirmed, the identity info goes here  CREATE TABLE IF NOT EXISTS /*_*/account_credentials ( -- Revision ID # acd_id int unsigned NOT NULL auto_increment PRIMARY KEY, -- Foreign key to user.user_id acd_user_id int unsigned NOT NULL, -- Optional 'real name' to be displayed in credit listings acd_real_name varchar(255) binary NOT NULL default '', -- Note: email should be restricted, not public info. -- Same with passwords. acd_email tinytext NOT NULL, -- Initially NULL; when a user's e-mail address has been -- validated by returning with a mailed token, this is   -- set to the current timestamp. acd_email_authenticated binary(14) default NULL, -- A little about this user acd_bio mediumblob NOT NULL, -- Private info for reviewers to look at when considering request acd_notes mediumblob NOT NULL, -- Links to recognize/identify this user, CSV, may not be public acd_urls mediumblob NOT NULL, -- IP address acd_ip VARCHAR(255) NULL default '', -- Name of attached file (.pdf,.doc,.txt etc...) acd_filename VARCHAR(255) NULL, acd_storage_key VARCHAR(64) NULL, -- Areas of interest acd_areas mediumblob NOT NULL, -- Timestamp of account registration. acd_registration char(14) NOT NULL, -- Timestamp of acceptance acd_accepted binary(14), -- The user who accepted it   acd_user int unsigned NOT NULL default 0, -- Reason given in email acd_comment varchar(255) NOT NULL default '' ) /*$wgDBTableOptions*/; CREATE UNIQUE INDEX /*i*/acd_user_id ON /*_*/account_credentials (acd_user_id,acd_id);


 * Be sure to add the database prefix where necessary.

-- (c) Aaron Schulz, 2007 ALTER TABLE /*$wgDBprefix*/account_requests ADD INDEX acr_type_del_reg (acr_type,acr_deleted,acr_registration); -- This stores all of credential information -- When accounts are confirmed, the identity info goes here CREATE TABLE IF NOT EXISTS /*_*/account_credentials (   -- Revision ID #    acd_id int unsigned NOT NULL auto_increment PRIMARY KEY,    -- Foreign key to user.user_id    acd_user_id int unsigned NOT NULL,    -- Optional 'real name' to be displayed in credit listings    acd_real_name varchar(255) binary NOT NULL default '',    -- Note: email should be restricted, not public info.    -- Same with passwords.    acd_email tinytext NOT NULL,    -- Initially NULL; when a user's e-mail address has been    -- validated by returning with a mailed token, this is    -- set to the current timestamp.    acd_email_authenticated binary(14) default NULL,    -- A little about this user    acd_bio mediumblob NOT NULL,    -- Private info for reviewers to look at when considering request    acd_notes mediumblob NOT NULL,    -- Links to recognize/identify this user, CSV, may not be public    acd_urls mediumblob NOT NULL, -- IP address acd_ip VARCHAR(255) NULL default '', -- Name of attached file (.pdf,.doc,.txt etc...) acd_filename VARCHAR(255) NULL, acd_storage_key VARCHAR(64) NULL, -- Areas of interest acd_areas mediumblob NOT NULL, -- Timestamp of account registration. acd_registration char(14) NOT NULL, -- Timestamp of acceptance acd_accepted binary(14), -- The user who accepted it   acd_user int unsigned NOT NULL default 0, -- Reason given in email acd_comment varchar(255) NOT NULL default '' ) /*$wgDBTableOptions*/; CREATE UNIQUE INDEX /*i*/acd_user_id ON /*_*/account_credentials (acd_user_id,acd_id);

Configuration
There are several configuration variables that can be adjusted in LocalSettings.php. (The default values are in SpecialConfirmAccount.php, but you should not edit that file).

Sysops can still create accounts directly. To disable this, to LocalSettings.php add: $wgGroupPermissions['*']['createaccount'] = false;

If only logged-in users are allowed to view pages, make sure you add the request account page to $wgWhitelistRead. For example: $wgWhitelistRead = array('Special:RequestAccount','Main Page');
 *  In other languages you have to replace "Special" and "Main Page" with the words that are used instead of special in your language like "Spezial" and "Hauptseite" in a German wiki, otherwise nobody will be able to create an account.

To further categorize users based on their interests, you can set up MediaWiki:Requestaccount-areas. This should be in a format like:
 * *Topic|Topic wiki page|text to append to all interested users' bios |text to append to all interested users' bios in group0|text to append to all interested users' bios group1|text to append to all interested users' bios in group2|...

These group numbers are based on. So if 0 is the index for 'authors', then 'authors' interested in a topic will have the group0 text appended to their biography. This can be useful, say, if users can be approved as either authors or editors. Authors can have "category:X authors" where X is a topic, like "mathematics", and editors can have "category:x editors". You can have as many groups as you want, but you need at least one.

Use

 * 1) As a bureaucrat (or other user with the confirmaccount permission), browse to Special:ConfirmAccounts
 * 2) Click Review
 * 3) You will see the whole form with the users' data. Carefully review the form, and proceed to creating the account or rejecting the request.
 * 4) If you chose to create the account, the user's biography will become their userpage and the userpage will be automatically created with the default summary of Creating user page with biography of new user.

Known issues

 * Do not set $wgGroupPermissions['*']['createaccount'] to true in LocalSettings, it will override the request login and allow users to sign up without confirmation.
 * Do not set MediaWiki:Requestaccount-areas/xx where xx is a language code, the first part of each line is used as the keys to store in the DB for the items account requesters check.
 * Older versions of MediaWiki may not show the link to Special:RequestAccount at the user login form. You can edit MediaWiki:loginprompt to remedy this.
 * Name collisions: account creations will be checked and stopped if it collides with a pending name. Requests are checked for pending/account name collisions too.
 * AuthPlugin stuff: If a central login is used, when accounts are confirmed and made, we may get name collisions if each wiki of the farm lets you request accounts on it. Collisions are dealt with by picking a new name.
 * If your email client loses its mail data before sending it out, users will not get their passwords but may have an account. Since no one knows the passwords, you may want to use Extension:Password Reset to send them new ones.
 * If only a few people view the confirm accounts page, the randomly triggered pruning of old request will not trigger often, so old rejected requests may persist.
 * Integration with LDAP Authentication extension

External link

 * Citizendium's account request form (ConfirmAccount and ConfirmEdit are enabled)
 * Hindupedia's account request form (ConfirmAccount is enabled)