Extension talk:ConfirmEdit

Jump to: navigation, search

About this board

By clicking "Add topic", you agree to our Terms of Use and agree to irrevocably release your text under the CC BY-SA 3.0 License and GFDL
2003:6F:8B2A:CC00:C3F:355E:4C59:6938 (talkcontribs)

I embed images in $wgCaptchaQuestions, thus I need to configure them with HTML.

This worked in MW 1.25, but in broke in MW 1.27 (I see the plain HTML).

CyberXRef (talkcontribs)

We've just upgraded from 1.25 to 1.27 and ConfirmEdit/QuestyCaptcha is indeed broken. It no longer allows HTML in $wgCaptchaQuestions which is critical for proper operation for us.

Zoglun (talkcontribs)

Any update on using image with wgCaptchaQuestions? We use image questions, too. This error preventing us upgrade to MW1.27.

Hutchy68 (talkcontribs)
This worked in MW 1.25, but in broke in MW 1.27 (I see the plain HTML).

Yes, I see this too and it needs to be addressed. Do we need a tracker? I'll look now.

Added a bug report, task T169124

Reply to "Allow HTML in $wgCaptchaQuestions?"
2604:880:64:2B3:8000:0:0:1000 (talkcontribs)

Does nocaptcha still work with confirmedit for stopping spam? It shows up and works when I test it but, I am getting a huge influx of spam with it on? I am running 1.28.2 with ConfirmEdit 1.4.0 but just getting smashed by account creations and spam. (talkcontribs)

Same problem. Massive influx of new accounts and spam since the end of April. Was using noCAPTCHA for account creation only, then enabled it for every edit and page creation, but it continues. My only recourse has been to disable account creation and remove edit/create permissions for every group and create a new group to add known real people to.

2604:880:64:2B3:0:0:0:2 (talkcontribs)

Same issue, I turned off nocaptcha and switched to some new custom questy captcha and still getting a huge influx of account creation through. It must be some issue with mediawiki/confirmedit that they can bypass everything

MarkAHershberger (talkcontribs)

I'm using it with MW 1.27. (talkcontribs)

and it is working? or it isnt?

MarkAHershberger (talkcontribs)

Sorry. I should have said it is working.

MarkAHershberger (talkcontribs)

Just noticed that the specs say you have to be using https. If you don't have https, I recommend using letsencrypt.

MarkAHershberger (talkcontribs)

Just re-verified that it is working to stop logins. It shows up for ConfirmAccount, but the result is ignored.

2605:A000:1207:608C:DC2D:434F:7CCA:6C68 (talkcontribs)

I am forcing HTTPS, http is redirected

Reply to "recaptcha nocaptcha being bypassed?" (talkcontribs)

The captcha loads and works fine until you click Login.

When clicking Login I receive: CAPTCHA verification failed due to internal error: http

And nothing else. As it's not descriptive I'm at a loss on what to try.

Has anyone seens this happen before?

Florianschmidtwelzow (talkcontribs)

Probably you can't establish http connection to the outside world from your server. Do you use a hosting provider (webspace, e.g.) or do you have ssh access to your server? (talkcontribs)

Yup get the same error, after upgrading to 2.28 from my old 2.22 instance. Firewall is blocking nothing

L Andy (talkcontribs)

I'm getting the same error: "CAPTCHA verification failed due to internal error: http"

This is on MediaWiki 1.27. As with the poster above, the server can make outbound connections on HTTP and HTTPS. Anyone have any ideas?

L Andy (talkcontribs)

This was my resolution to the issue.

The "internal error: http" message means simply that ConfirmEdit failed to execute an http request against the Google servers, which could happen for a number of reasons. The MW and PHP logs don't seem to be helpful in determining why. If you save the following as a PHP script on your web site and browse to it, it will execute an http request, similar to how ConfirmEdit tries to do, and return the result of curl_error() which should give more detailed error information:

<title> cURL Test Script </title>

    if (!function_exists('curl_init'))
        print 'cURL not installed';
        $ch = curl_init($Url);
        curl_setopt($ch, CURLOPT_TIMEOUT, 10);

        if(curl_exec($ch)) { print 'OK';}
        else { print curl_error($ch);}

In my case, the error was "SSL certificate problem: unable to get local issuer certificate". It turns out this is because a default PHP install (at least on Windows) doesn't have access to any trusted root certificates, so can't validate SSL connections. The fix was to download a set of root certificates provided by the cURL project at https://curl.haxx.se/docs/caextract.html, and add the following to php.ini:

curl.cainfo = C:\SomeFolder\cacert.pem
Reply to "reCAPTCHA noCAPTCHA failing"

Correct NoCaptcha's won't get validated

4 (talkcontribs)

I have weird problem on a private wiki in my company. Placed a NoCaptcha on create account form using ConfirmEdit. Eveyrime people try to create an account with a correct captcha, they get 'Incorrect or missing CAPTCHA.' Is this a bug?

MarkAHershberger (talkcontribs)

Maybe it has something to do with trying to use NoCaptcha on a closed network? (talkcontribs)

Same issue on an open wiki. It used to work but now 'Incorrect or missing CAPTCHA.' comes up when editing pages...

MarkAHershberger (talkcontribs)

I suspect recent changes in Google's CAPTCHA are to blame. Here is a bug with a patch to try: Phab:T160262

Reply to "Correct NoCaptcha's won't get validated"
Invisible Bee (talkcontribs)


Would the module included work for the new Invisible reCAPTCHA?

Google documentation as follows:



MarkAHershberger (talkcontribs)

It looks like support would have to be added. To be sure, I've filed a phabricator task: https://phabricator.wikimedia.org/T160262

Reply to "Invisible reCAPTCHA support"

Fatal error when I try "Log in / create account"

Unikum~mediawikiwiki (talkcontribs)

I use trunk version of this extention and MW 1.18. When I click Log in / create account I recieave fatal error:

Fatal error: Call to undefined method WebRequest::getIP() in /srv/http/wiki/extensions/ConfirmEdit/Captcha.php on line 202

This post was posted by Unikum~mediawikiwiki, but signed as Unikum.

Subfader (talkcontribs)

Try the latest version of ConfirmEdit

Unikum~mediawikiwiki (talkcontribs)

I use trunk version from SVN (last update at 2011-12-17).

This post was posted by Unikum~mediawikiwiki, but signed as Unikum.

JonathanWilliford (talkcontribs)

You need to use the REL1_18 branch for both your main MW install and this extension. You can fix this by going to your ConfirmEdit directory and running:

svn switch http://svn.wikimedia.org/svnroot/mediawiki/branches/REL1_18/extensions/ConfirmEdit

Apparently, the change with getIP() hasn't been propagated to the REL1_18 branch.

Unikum~mediawikiwiki (talkcontribs)

Thanks for the tip.

This post was posted by Unikum~mediawikiwiki, but signed as Unikum.

Unikum~mediawikiwiki (talkcontribs)

Problem appears since r106097.

This post was posted by Unikum~mediawikiwiki, but signed as Unikum. (talkcontribs)

For MW 1.16.5 with r107316 I have solved this problem by changing

$wgRequest->getIP() to wfGetIP() (talkcontribs)

For MW 1.16.5 with r107316 I have solved this problem by changing

$wgRequest->getIP() to wfGetIP()

Platonides (talkcontribs)

You were using a very recent ConfirmEdit with an old MediaWiki.

Brted (talkcontribs)

I got this error when I installed 1.18.3 today. New MW, new ConfirmEdit. I fixed it by bringing over my old copy of captcha.php. That version uses wfGetIP() Brted (talk) 02:01, 29 April 2012 (UTC) (talkcontribs)

In my case it was Asirra that was causing the problem. I manually downloaded the latest version of that and overwrote the files in the ConfirmEdit directory with it. All works fine now. (talkcontribs)

In my case I just changed entire return string with just 'return 1;' becase this line just check bad login key case, so I chose to pass this needless process. It works also.

Reply to "Fatal error when I try "Log in / create account"" (talkcontribs)


I have a problem with ConfirmEdit

RecaptchaNoCaptcha didn't work, Recaptcha work well but not Nocaptcha by Google It does not appear. And Recaptcha does not work against bots :/

Before i used AreYouHuman but the service stopped

My mediawiki have:

- CollapsibleVector  

- ConfirmEdit      

- Gadgets  

- Interwiki          

- MobileFrontend    

- Nuke            

- PdfHandler  

- Renameuser      

- SpamBlacklist          

- TitleBlacklist  

- VisualMathCaptcha

- Cite              

- Confirm            

- DeleteBatch      

- FlashMP3  

- ImageMap  

- LocalisationUpdate  

- MultimediaPlayer  

- OpenGraphMeta    

- Poem        

- SyntaxHighlight_GeSHi  

- ToggleDisplay  

- WebChat

- CiteThisPage      

- ConfirmEdit        

- Description2    

- Flow      

- InputBox  

- MobileApp          

- MwEmbedSupport    

- ParserFunctions  

- TimedMediaHandler      

- Vector          

- WikiEditor

Are there any incompatibilities with this extensions ?

Have you an idea ?


Florianschmidtwelzow (talkcontribs)

What do you see on the page? Is there a text, that you need to solve a captcha, but doesn't see any captcha only? What does the browser console say? (talkcontribs)

I'm in the same boat it just says "To protect the wiki against automated account creation, we kindly ask you to solve the following CAPTCHA:" but there's no NoCaptcha embed. (talkcontribs)

I experience the very same problem. (talkcontribs)

The console displays an error "Error: Missing required parameters in RecaptchaOptions: sitekey" But I followed the guide written here and correctly pasted the site key to LocalSettings.php. At least, I hope I did it correctly. (talkcontribs)

Fixed it. It was my own stupidity and lack of attention. I still had it set to the old $wgReCaptchaPublicKey instead of the $wgReCaptchaSiteKey required by NoCaptcha. (talkcontribs)

Thanks, i was stupid too, but now it works ! :P (talkcontribs)

One more stupid here! lol Thanks for the quick fix!

Reply to "NoCaptcha Mediawiki 1.26"

Force only and all anonymous IPs into a CAPTCHA?

Schiffy (talkcontribs)

So I'm trying to make it so anyone who is not logged in has to always answer a QuestyCaptcha, be it editing, creating pages, or making an account, but once a user is logged in they no longer have to.

I've tried the following method:

wfLoadExtensions( array( 'ConfirmEdit', 'ConfirmEdit/QuestyCaptcha' ) );
$wgCaptchaClass = 'QuestyCaptcha';
$arr = array (
        //Questions and answers are in this array
foreach ( $arr as $key => $value ) {
        $wgCaptchaQuestions[] = array( 'question' => $key, 'answer' => $value );

$wgGroupPermissions['user']['skipcaptcha'] = true;

This seems to have worked once, but now anonymous IPs can edit any page without running into a CAPTCHA, and only hit one on account creation. Is there a way to put this back how I intended, where only logged in users can bypass CAPTCHAs, and anonymous IPs run into them in all cases?

MarkAHershberger (talkcontribs)

It looks like you want EmergencyCaptcha mode.

Schiffy (talkcontribs)

I was looking at that, but I'm not clear on one thing - does that only apply to anonymous IPs like what I'm looking to do?

MarkAHershberger (talkcontribs)

Anonymous IPs and new users. So a bit more than just what you wanted, but it is pretty close and after users have made a few edits, the captcha goes away.

Also look at this patch (which should probably be put in the main code).

Also, note that you want the following, not $wmgEmergencyCaptcha:

$wgCaptchaTriggers['edit']          = true; 
$wgCaptchaTriggers['create']        = true;
Reply to "Force only and all anonymous IPs into a CAPTCHA?"

Namespace triggers not working correctly

1 (talkcontribs)

I am using ConfirmEdit with the QuestyCaptcha on my installation and my users have started complaining that they are always required to complete the captcha when editing. It is supposed to be configured such that regular edits don't provoke the captcha, but I had specifically enabled the edit trigger for the NS_FILE namespace to catch uploads of new versions of images, as that was previously used as an attack on the site. When I disabled the namespace specific trigger, it stopped prompting on the main namespace too. Is this a known issue at the moment?

For reference my relevant configuration excerpt is:

$wgGroupPermissions['*'            ]['skipcaptcha'] = false;
$wgGroupPermissions['user'         ]['skipcaptcha'] = false;
$wgGroupPermissions['autoconfirmed']['skipcaptcha'] = false;
$wgGroupPermissions['bot'          ]['skipcaptcha'] = true; // registered bots
$wgGroupPermissions['sysop'        ]['skipcaptcha'] = true;
$wgCaptchaTriggers['edit']          = false;
$wgCaptchaTriggers['create']        = true;
$wgCaptchaTriggers['addurl']        = true;
$wgCaptchaTriggers['createaccount'] = true;
$wgCaptchaTriggers['move']          = true;
$wgCaptchaTriggers['badlogin']      = true;
$wgCaptchaTriggersOnNamespace = array();
$wgCaptchaTriggersOnNamespace[NS_FILE]['edit'] = true;
Reply to "Namespace triggers not working correctly"
Star Warden (talkcontribs)

Hi. Our captcha trigger seems to be malfunctioning since this morning and there have already appeared some spammy accounts. I am getting these errors while on the login page (http://dragon-mania-legends-wiki.mobga.me/Special:UserLogin):

Notice: Undefined index: badlogin /srv/dml-wiki/extensions/ConfirmEdit/SimpleCaptcha/Captcha.php on line 348

Notice: Undefined index: badloginperuser in /srv/dml-wiki/extensions/ConfirmEdit/SimpleCaptcha/Captcha.php on line 365

and on the create account page (http://dragon-mania-legends-wiki.mobga.me/Special:CreateAccount):

Notice: Undefined index: createaccount in /srv/dml-wiki/extensions/ConfirmEdit/SimpleCaptcha/Captcha.php on line 924

I don't understand why it does that since we're using QuestyCaptcha and not SimpleCaptcha. Deleting the folder brings the wiki down. I tried disabling SimpleCaptcha in /ConfirmEdit/extension.json under AutoloadClasses (line 51), but no luck.

We're using the REL1_27 version of ConfirmEdit. I disabled create accounts, for now, so the error on the createaccount page cannot be seen, but the ones on the login page can be seen. The console doesn't display any related java errors, so I am not sure what's causing it....

The exact same issue happens on the wiki, used for testing purposes, installed on my PC (through xampp).

Kghbln (talkcontribs)

When updating from MW 1.25 to MW 1.27 a couple of days ago did you also really upgrade ConfirmEdit from REL1_25 to REL1_27?

Now with REL1_27 you should add something like the following to you "LocalSettings.php" when using e.g. ReCaptcha:

## ConfirmEdit
wfLoadExtensions( array(
$wgCaptchaClass = 'ReCaptchaNoCaptcha';
$wgReCaptchaSiteKey = 'myKey';
$wgReCaptchaSecretKey = 'mySecretKey';
$wgCaptchaTriggers['edit'] = true;
$wgCaptchaTriggers['create'] = true;
// $wgCaptchaTriggers['addurl'] = false;
Kghbln (talkcontribs)

Yeah, indeed you are on REL1_27 so I suspect the configuration as the cause.

Star Warden (talkcontribs)

Hey. We are not using ReCaptcha, but QuestyCaptcha. This is the configuration. I will replace the answers themselves with 'answer#', for security reasons.

wfLoadExtensions( array( 'ConfirmEdit', 'ConfirmEdit/QuestyCaptcha' ) );
$wgCaptchaClass = 'QuestyCaptcha';
$wgCaptchaQuestions[] = array( 'question' => "What game does this wiki cover?", 'answer' => array( 'answer1', 'answer2', 'answer3', 'answer4', 'answer5', 'answer6' ) );
$wgCaptchaTriggers['wikiforum'] = true;
$wgGroupPermissions['autoconfirmed']['skipcaptcha'] = true;
Star Warden (talkcontribs)

Hi again. I tried using ReCaptcha, as well. This was the configuration:

wfLoadExtensions( array( 'ConfirmEdit', 'ConfirmEdit/ReCaptchaNoCaptcha' ) );
$wgCaptchaClass = 'ReCaptchaNoCaptcha';
$wgReCaptchaSiteKey = 'key';
$wgReCaptchaSecretKey = 'key';

But it still shows the same undefined indexes related to SimpleCaptcha. Isn't there a way to get rid of SimpleCaptcha? I just want to use Questy. It worked wonders, so far.

Star Warden (talkcontribs)

Also, both ConfirmEdit and the MediaWiki software are on 1_27.

Kghbln (talkcontribs)

That's strange. I run several wikis with 1.27.1 and ConfirmEdit without getting this. My QuestyCaptcha setup is however a bit different:

## ConfirmEdit
wfLoadExtensions( array(
$wgCaptchaClass = 'QuestyCaptcha';
$wgCaptchaTriggers['edit'] = true;
$wgCaptchaTriggers['create'] = true;
// $wgCaptchaTriggers['addurl'] = false;
$arr = array(
        "MyQuestion" => "MyAnswer",
        "MyQuestion" => "MyAnswer",
        "MyQuestion" => "MyAnswer"
foreach ( $arr as $key => $value ) {
        $wgCaptchaQuestions[] = array(
        	'question' => $key,
		'answer' => $value
Star Warden (talkcontribs)

Well, I tried using your configuration and I am still getting the same issues. I even re-downloaded ConfirmEdit and run both composer update and php update.php. What is happening?

Star Warden (talkcontribs)

Okay, now that's very strange. The issue fixed itself after I moved the entire code at the bottom of localsettings.php... But why? Why was the position important?

Also, I assume two different captchas can't be used at the same time, right? Like QuestyCaptcha + ReCaptcha.

I've wrote more details about the whole issue and the workaround to it here: https://www.mediawiki.org/wiki/Topic:Temsrqh8dj4mbpgg

Kghbln (talkcontribs)

No, two different CAPTCHAS cannot be used at a time and yes the position within the "LocalSettings.php" makes a difference in some cases. Thanks for linking to the related topic.

Reply to "Captcha Issues"