Release status: stable
|Description||Adds CAPTCHAs for page saves and other user actions|
|Latest version||1.6.0 (Continuous updates)|
|Compatibility policy||Snapshots releases along with MediaWiki. Master is not backward compatible.|
|License||GNU General Public License 2.0 or later|
|Quarterly downloads||188 (Ranked 48th)|
|Public wikis using||957 (Ranked 278th)|
|Translate the ConfirmEdit extension if it is available at translatewiki.net|
|Issues||Open tasks · Report a bug|
The ConfirmEdit extension lets you use various different CAPTCHA techniques, to try to prevent spambots and other automated tools from editing your wiki, as well as to foil automated login attempts that try to guess passwords.
ConfirmEdit ships with several techniques/modules to generate captcha.
|Module||Description||Effectiveness at stopping spam|
||Users have to solve a simple math problem.||Low|
||Users have to identify a series of characters, displayed in a stylized way.||Low|
||Users have to solve a math problem that's displayed as an image.||Low|
||Users have to answer a question, out of a series of questions defined by the administrator(s).||Very high, until cracked|
||Similar to reCAPTCHA, but is arguably more effective than reCAPTCHA because of its different approach to accessibility-friendly captchas.||Unknown|
Some of these modules require additional setup work:
- MathCaptcha requires both the presence of TeX and, for versions of MediaWiki after 1.17, the Math extension;
- FancyCaptcha requires running a preliminary setup script in Python.
CAPTCHAs reduce accessibility and cause inconvenience to human users.
They also are not 100% effective against bots, and they will not protect your wiki from spammers who are willing and able to use human labor to get through the CAPTCHAs. You may wish to use ConfirmEdit in conjunction with other anti-spam features. Regardless of the solution you use, if you have a publicly-editable wiki it's important to keep monitoring the "Recent changes" page.
- Download and place the file(s) in a directory called
- Add the following code at the bottom of your LocalSettings.php file:
wfLoadExtension( 'ConfirmEdit' );
- Enable the CAPTCHA type which should be used
- Configure as needed
- Done – Navigate to Special:Version on your wiki to verify that the extension is successfully installed.
- If using Vagrant, install with
vagrant roles enable confirmedit --provision
There are numerous different CAPTCHA types included with ConfirmEdit.
This module presents a question and the user supplies the answer. You provide the questions in the configuration. This module has proven to offer a strong mechanism against spambots; it should also have the advantage of better accessibility, as textual questions can be read by text-to-speech software allowing visually impaired users (but not bots) to answer correctly.
Add the following to
LocalSettings.php to enable this CAPTCHA, editing the Q&A:
wfLoadExtensions([ 'ConfirmEdit', 'ConfirmEdit/QuestyCaptcha' ]); // Add your questions in LocalSettings.php using this format: $wgCaptchaQuestions = [ 'What is the capital of France?' => 'Paris', 'What is the capital of Spain' => 'MADRID', // Answers are case insensitive 'What is the name of this wiki?' => $wgSitename, // You can use variables 'How many fingers does a hand have?' => [ 5, 'five' ], // A question may have many answers ];
It will randomly choose a question from those supplied.
The minimum is one.
- QuestyCaptcha is case-insensitive. If the answer is "Paris" and the user writes "paris", or if the answer is "paris" and the user writes "Paris", it will still work.
- If the answer has a special character like "ó", you may write an answer with "ó" and another with "o" (where "o" replaces "ó"), just in case. For example, if the answer is "canción" you can use
[ 'cancion', 'canción' ]in case the user writes "cancion".
- The answer must be easy to guess for a human interested in your wiki, but not by an automatic program. Ideally, it should not be contained in the text of the question; you can try and edit the captcha help messages and provide the solution to the captcha response there.
- Just change the questions when/if they start proving ineffective; this may never happen if your wiki is not specifically targeted.
- Don't ever reuse questions already used by you or others in the past: spambots are known to remember a question and its answer forever once they broke it.
- You can even dynamically generate questy captchas in the configuration. DO NOT use an exact copy of the dynamic questions from the link, they've been cracked by spammers. However, other dynamic questions in the style of the questions presented are highly effective.
- There is a separate extension to ConfirmEdit called QuestyCaptchaEditor which provides an on-wiki special page for managing QuestyCaptcha question+answer(s) pairings. You may wish to consider installing it if it's desirable to reduce sysadmin intervention when it comes to managing the CAPTCHA questions and their answers.
This module implements the new ReCaptcha NoCaptcha solution in ConfirmEdit.
You still need a public and a secret key (which you can retrieve from the ReCaptcha admin panel – change v2, v3 not work) and install the plugin with:
wfLoadExtensions([ 'ConfirmEdit', 'ConfirmEdit/ReCaptchaNoCaptcha' ]); $wgReCaptchaSiteKey = 'your public/site key here'; $wgReCaptchaSecretKey = 'your private key here';
There is an additional configuration option for this module,
false), which, if set to
true, sends the IP address of the current user to a server from Google while verifying the CAPTCHA.
You can improve the privacy for your users if you keep this set to
This will only work on standard MediaWiki editor.
Currently there is no official way to implement version 3 of Google reCAPTCHA.
This is the default CAPTCHA.
This module provides a simple addition or subtraction question for the user.
Add the following lines to
LocalSettings.php in the root of your MediaWiki to enable this CAPTCHA:
$wgCaptchaClass = 'SimpleCaptcha';
Note that the display of a trivial maths problem as plaintext yields a captcha which can be trivially solved by automated means; as of 2012, sites using SimpleCaptcha are receiving significant amounts of spam and many automated registrations of spurious new accounts. Wikis currently using this as the default should therefore migrate to one of the other CAPTCHAs.
This module displays a stylized image of a set of characters.
Pillow must be installed in order to create the set of images initially, but isn't needed after that (can be installed with
pip install Pillow in most environments).
- Add the following lines to
LocalSettings.phpin the root of your MediaWiki installation:
wfLoadExtensions([ 'ConfirmEdit', 'ConfirmEdit/FancyCaptcha' ]);
$wgCaptchaClass = 'FancyCaptcha';
LocalSettings.php, set the variable
$wgCaptchaDirectoryto the directory where you will store Captcha images. Below it set
$wgCaptchaSecretto your passphrase.
- Create the images by running the following:
python /path/to/captcha.py --font=<font> --wordlist=<wordlist> --key=<key> --output=<output> --count=<count>
- where font is a path to some font, for instance AriBlk.TTF.
- wordlist is a path to some word list, for instance
/usr/share/dict/words. (Note: on Debian/Ubuntu, the 'wbritish' and 'wamerican' packages provide such lists. On Fedora, use the 'words' package)
- key is the exact passphrase you set
$wgCaptchaSecretto. Use quotes if necessary.
- output is the path to where the images should be stored (defined in
- count is how many images to generate.
- An example, assuming you're in the
extensions/ConfirmEditdirectory (font location from Ubuntu 6.06, probably different on other operating systems):
python captcha.py --font=/usr/share/fonts/truetype/freefont/FreeSans.ttf --wordlist=/usr/share/dict/words --key=FOO --output=../../../captcha --count=100
- If you are not satisfied with the results of the words you've generated you can simply remove the images and create a new set. Comic_Sans_MS_Bold.ttf seems to generate relatively legible words, and you could also edit the last line of captcha.py to increase the font size from the default of 40.
- Put the images you get into
captchadirectory in your installation.
- Edit your wiki's LocalSettings.php: specify full path to your captcha directory in
$wgCaptchaDirectoryand secret key you've been using while generating captures in
$wgCaptchaDirectory = "/.php-data/my-wiki.org/wiki/captcha"; $wgCaptchaDirectoryLevels = 0; // Set this to a value greater than zero to break the images into subdirectories $wgCaptchaSecret = "FOO"; // Same value you used in --key option in captcha.py
See also wikitech:Generating CAPTCHAs for how Wikimedia Foundation does it.
- How to avoid common problems running Python on Windows
- Install the most recent version of Pillow.
- Make the installation of Python on a short folder name, like C:\Python\
- Create a folder like C:\Ex and place files CAPTCHA.py / FONT.ttf / LIST.txt into the folder.
- To execute easily, run the following example as a batch file:
C:\python\python.exe C:\Ex\CAPTCHA.py --font C:\Ex\FONT.ttf --wordlist C:\Ex\LIST.txt --key=YOURPASSWORD --output C:\Ex\ --count=20
This module generates an image using TeX to ask a basic math question.
Set the following to enable this CAPTCHA:
wfLoadExtensions([ 'ConfirmEdit', 'ConfirmEdit/MathCaptcha' ]);
README file in the math folder to install this captcha.
The configuration is similar to ReCaptcha:
wfLoadExtensions([ 'ConfirmEdit', 'ConfirmEdit/hCaptcha' ]); $wgHCaptchaSiteKey = 'your public/site key here'; $wgHCaptchaSecretKey = 'your private key here';
$wgHCaptchaSendRemoteIP is also available.
Don't require CAPTCHA from some users
ConfirmEdit introduces a
'skipcaptcha' permission type to wgGroupPermissions.
This lets you set certain groups to never see CAPTCHAs.
All of the following can be added to
$wgGroupPermissions['*']['skipcaptcha'] = false; $wgGroupPermissions['user']['skipcaptcha'] = false; $wgGroupPermissions['autoconfirmed']['skipcaptcha'] = false; $wgGroupPermissions['bot']['skipcaptcha'] = true; // registered bots $wgGroupPermissions['sysop']['skipcaptcha'] = true;
To skip captchas for users that confirmed their email, you need to set both:
$wgGroupPermissions['emailconfirmed']['skipcaptcha'] = true; $wgAllowConfirmedEmail = true;
Set actions that require CAPTCHA
The following conditions can trigger a CAPTCHA to be displayed:
- 'edit' - triggered on every attempted page save
- 'create' - triggered on page creation
- 'sendemail' - triggered when using Special:Emailuser
- 'addurl' - triggered on a page save that would add one or more URLs to the page
- 'createaccount' - triggered on creation of a new account
- 'badlogin' - triggered after several failed login attempts from the same IP address
- 'badloginperuser' - triggered after several failed login attempts using the same username
The default values for these are:
$wgCaptchaTriggers['edit'] = false; $wgCaptchaTriggers['create'] = false; $wgCaptchaTriggers['sendemail'] = false; $wgCaptchaTriggers['addurl'] = true; $wgCaptchaTriggers['createaccount'] = true; $wgCaptchaTriggers['badlogin'] = true; $wgCaptchaTriggers['badloginperuser'] = true;
addurl can be configured per namespace using the
If there is no
$wgCaptchaTriggersOnNamespace for the current namespace, the normal
So suppose that in addition to the above
$wgCaptchaTriggers defaults we configure the following:
$wgCaptchaTriggersOnNamespace[NS_TALK]['addurl'] = false; $wgCaptchaTriggersOnNamespace[NS_PROJECT]['edit'] = true;
Then the CAPTCHA will not trigger when adding URLs to a talk page, but on the other hand user will need to solve a CAPTCHA any time they try to edit a page in the project namespace, even if they aren't adding a link.
URL and IP whitelists
It is possible to define a whitelist of known good sites for which the CAPTCHA should not kick in, when the
'addurl' action is triggered.
Sysop users can do this by editing the system message page called MediaWiki:Captcha-addurl-whitelist.
The expected format is a set of regex's one per line.
Comments can be added with
You can see an example of this usage on OpenStreetMap.
This set of whitelist regexes can also be defined using the
$wgCaptchaWhitelist config variable in
LocalSettings.php, to keep the value(s) a secret.
Some other variables you can add to
- $wgCaptchaWhitelistIP - List of IP ranges to allow to skip the CAPTCHA (you can also use MediaWiki:Captcha-ip-whitelist; see below for details).
- $ceAllowConfirmedEmail - Allow users who have confirmed their e-mail addresses to post URL links
These are described more thoroughly in the code comments
MediaWiki:Captcha-ip-whitelist can be used to change the whitelisted IP addresses and IP ranges on wiki.
They should be separated by newlines.
If any other character (apart from a valid IP address or range) is found on a line, it will be ignored but leading and trailing whitespace characters are allowed.
For example, a line with only
127.0.0.1 is considered valid but
#127.0.0.1 will be ignored.
The global variable wgCaptchaRegexes accepts an array of regexes to be tested against the page text and will trigger the CAPTCHA in case of a match.
Failed login attempts
When using the
badloginperuser triggers, the following configuration variables control how many failed login attempts per-IP and per-user are allowed before a CAPTCHA is required, and how long it takes until the CAPTCHA requirement expires:
$wgCaptchaBadLoginAttempts = 3; $wgCaptchaBadLoginExpiration = 300; // 300 seconds = 5 minutes $wgCaptchaBadLoginPerUserAttempts = 20; $wgCaptchaBadLoginPerUserExpiration = 600; // 600 seconds = 10 minutes
The triggers require $wgMainCacheType to be set to something other than
CACHE_NONE in your
LocalSettings.php, if in doubt the following will always work.
$wgMainCacheType = CACHE_ANYTHING;
Note that these triggers not trigger CAPTCHAs on API login, but instead block them outright until the CAPTCHA requirement expires.
For example, Wikimedia Foundation wikis use FancyCaptcha with a custom set of images and the default configuration, modified by what follows.
$wgGroupPermissions['autoconfirmed']['skipcaptcha'] = true;
This means only unregistered and newly registered users have to pass the CAPTCHA.
Additionally the shortcut named
$wmgEmergencyCaptcha is designed for use in a limited number of emergency situations, for instance in case of massive vandalism or spam attacks: it changes the default trigger values (see above) into the following:
$wgCaptchaTriggers['edit'] = true; $wgCaptchaTriggers['create'] = true;
So all anonymous and new users have to solve a CAPTCHA also before being able to save an edit or create a new page, in addition to the normal situation.
ConfirmEdit supports rate limiting for false CAPTCHA.
The basic framework was designed largely by Brion Vibber, who also wrote the SimpleCaptcha and FancyCaptcha modules.
The MathCaptcha module was written by Rob Church.
The QuestyCaptcha module was written by Benjamin Lees.
Additional maintenance work was done by Yaron Koren.
- MediaWiki:Questycaptchahelp-text, MediaWiki:Questycaptcha-edit, MediaWiki:Questycaptcha-addurl, MediaWiki:Questycaptcha-create, MediaWiki:Questycaptcha-createaccount
- Google Blog Are you a robot? Introducing “No CAPTCHA reCAPTCHA” ()
- Anti-spam features
|This extension is being used on one or more Wikimedia projects. This probably means that the extension is stable and works well enough to be used by such high-traffic websites. Look for this extension's name in Wikimedia's CommonSettings.php and InitialiseSettings.php configuration files to see where it's installed. A full list of the extensions installed on a particular wiki can be seen on the wiki's Special:Version page.|
|This extension is included in the following wiki farms/hosts and/or packages:|