Extension talk:ConfirmEdit

About this board

Archives 
Uvas magicas (talkcontribs)

hi, exist a form of install with this extension the recaptchaNocaptcha of google in the version 3?

200.124.206.29 (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?

79.211.153.1 (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:

<html>
<head>
<title> cURL Test Script </title>
</head>
<body>
<?php
    $Url='https://wtfismyip.com/text';

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

        if(curl_exec($ch)) { print 'OK';}
        else { print curl_error($ch);}
        
        curl_close($ch);
    }
?>
</body>
</html>

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]
curl.cainfo = C:\SomeFolder\cacert.pem
Vasad36 (talkcontribs)
Reply to "reCAPTCHA noCAPTCHA failing"

Can I use different Captcha methods for different actions?

2
Lakejason0 (talkcontribs)

I'd like to use QuestyCaptcha on account creation and hCaptcha for adding urls, bad logins etc. Is it possible to do that?

CayceP (talkcontribs)

As far as I know the method is global on the wiki, so you need to choose one (I recommend the QuestyCaptcha one since this one seems to be the only that keep bots away).

Reply to "Can I use different Captcha methods for different actions?"

ConfirmEdit or Google ReCaptcha v2 not working?

9
Chuck.Kahn (talkcontribs)

Recent flood of new spam users on my Wiki over the last 12 days.


https://chuckipedia.ca/index.php/Special:Log/newusers


How do I stop this flood? I've had ConfirmEdit installed with Google ReCaptcha v2 on this Wiki since 16/08/2018. Did Google ReCaptcha v2 change something? I have been using the same set of Google ReCaptcha keys on two different Wiki domains. Was that the problem? I just now created separate keys for each Wiki. The other Wiki's newuser list is here:


https://worldwideboxoffice.com/wiki/index.php/Special:Log/newusers


And here's my LocalSettings.php setting:


wfLoadExtensions([ 'ConfirmEdit', 'ConfirmEdit/ReCaptchaNoCaptcha' ]);

$wgCaptchaClass = 'ReCaptchaNoCaptcha';

$wgReCaptchaSiteKey = 'your public/site key here';

$wgReCaptchaSecretKey = 'your private key here';


I opened a Chrome Guest window and was freely able to create a Test page on my Wikis without being logged in. Shouldn't ConfirmEdit be... confirming the creation of new pages in that situation?

Dinoguy1000 (talkcontribs)

I was going to say that ConfirmEdit + ReCaptcha v2 is incompatible with VisualEditor (per these edits), but it appears that your wikis don't use VisualEditor. I guess this module is simply broken somehow.

I can't offer a fix, but I will suggest that if you can, to switch to the QuestyCaptcha module; with unique question/answer pairs, it completely eliminates automated spam unless the spammer decides to specifically target your wikis (and even then, you can simply switch out the question/answer pairs).

Chuck.Kahn (talkcontribs)

So I #-d out the ReCaptcha lines and added these QuestyCaptcha lines and tried creating a Test7 page in a Guest Chrome window and again got no prompt. Same creating a Test8 page from another PC.


wfLoadExtensions([ 'ConfirmEdit', 'ConfirmEdit/QuestyCaptcha' ]);

$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

];

Chuck.Kahn (talkcontribs)

Tried creating a new page today in a Guest Window and was prompted with the QuestCaptcha question 'What is the capital of Spain' -- so it works now. I didn't change anything from yesterday but today it works.

Chuck.Kahn (talkcontribs)

Got a ton of spam today so I changed the QuestyCaptcha questions. Anything else I should try?

Dinoguy1000 (talkcontribs)

The questions you set for QuestyCaptcha shouldn't be generic. Ideally they'll reflect the subject of your wiki, and shouldn't be super-obvious without at least a passing familiarity with the subject (though you should also be careful not to make them too obscure). The questions in the code you posted in response to my first comment are all bad ideas for actual questions to use, especially since they appear directly on the extension page here as examples of questions.

With proper question/answer pairs, QuestyCaptcha is going to be one of the most effective anti-spam measures you can install that still allow for normal editing with minimal hassle.

Chuck.Kahn (talkcontribs)

Saw the main page of my wiki was vandalized today. I opened a guest window in Chrome and was able to edit the main page -- no QuestyCaptcha prompt needed. Then I added these lines to LocalSettings.php:


$wgMainCacheType    = CACHE_ANYTHING;

$wgCaptchaTriggers['edit']          = true;

$wgCaptchaTriggers['create']        = true;

$wgCaptchaTriggers['createtalk']    = true;

$wgCaptchaTriggers['addurl']        = true;

$wgCaptchaTriggers['createaccount'] = true;

$wgCaptchaTriggers['badlogin']      = true;


And the QuestyCaptcha prompt appeared. Here I was adding harder and harder questions to QuestyCaptcha every time spam appeared and it turns out it wasn't the questions but these added option lines that are needed.

Dinoguy1000 (talkcontribs)

QuestyCaptcha isn't intended to stop vandalism, but to stop automated spam. Vandalism is almost always done by humans, so any questions that allow for normal editing are going to be trivially defeated by vandals. You should instead use other tools for antivandalism, such as protecting high-traffic pages that shouldn't be edited often (e.g. your main page, and any very widely used templates), and installing and configuring AbuseFilter. QuestyCaptcha itself should usually only be configured to trigger on account creations and bad logins, and on page creations and new external link insertions for anonymous or non-autoconfirmed editors.

60.251.70.131 (talkcontribs)

Hi All

I have same problem.

Does not show proper ReCaptcha, show text "CAPTCHA" only. :(

Reply to "ConfirmEdit or Google ReCaptcha v2 not working?"

Skipcaptcha not working for custom usergroups

1
91.125.240.46 (talkcontribs)

I have a few custom usergroups on my wiki and am using ConfirmEdit as we've been hit by a lot of spam recently. I'd like trusted staff and those with lots of edits (which I have custom usergroups for) to bypass the captcha - but even though I have it set up like the below, they're still getting the captcha showing because they're in the emailconfirmed/autoconfirmed/users group as well. Any ideas?

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

Reply to "Skipcaptcha not working for custom usergroups"

Using hCaptcha on MediaWiki 1.31-1.34

1
Summary last edited by SunAfterRain 11:31, 14 April 2022 4 months ago

There is a quick hack you can use to get hCaptcha kind of working on MediaWiki 1.31-1.34. This is not an official backport—use at your own risk. I'm not liable for any potential security breach that may result from these changes.

  1. Change line 139 protected function addCaptchaAPI( (as seen at https://github.com/wikimedia/mediawiki-extensions-ConfirmEdit/blob/master/hCaptcha/includes/HCaptcha.php#L139) to public function addCaptchaAPI(.
  2. Remove the call to the addCSPSources() method on line 41 of HTMLHCaptchaField.php, since pre-1.35 doesn't offer support for this (as seen at https://github.com/wikimedia/mediawiki-extensions-ConfirmEdit/blob/master/hCaptcha/includes/HTMLHCaptchaField.php#L41).
MyWikis-JeffreyWang (talkcontribs)

There is a quick hack you can use to get hCaptcha kind of working on MediaWiki 1.31-1.34. This is not an official backport—use at your own risk. I'm not liable for any potential security breach that may result from these changes.

  1. Change line 139 protected function addCaptchaAPI( (as seen at https://github.com/wikimedia/mediawiki-extensions-ConfirmEdit/blob/master/hCaptcha/includes/HCaptcha.php#L139) to public function addCaptchaAPI(.
  2. Remove the call to the addCSPSources() method on line 41 of HTMLHCaptchaField.php, since pre-1.35 doesn't offer support for this (as seen at https://github.com/wikimedia/mediawiki-extensions-ConfirmEdit/blob/master/hCaptcha/includes/HTMLHCaptchaField.php#L41).

QuestyCaptcha not preventing account creation

6
SheldonBole (talkcontribs)

I have QuestyCaptcha setup on my wiki. When I go to Request account, I see the QuestyCaptcha question, but whether I enter a correct or incorrect value the account request is processed, i.e. I see the resulting "Your account request has been sent and is now pending review. A confirmation email has been sent to your email address." Additionally, when I look under Open account requests the account request does appear there.

The site is on:

MediaWiki R1.34

PHP V 7.3.17

ConfirmEdit section in LocalSettings.php looks as follows:

// QuestyCaptcha Settings

   wfLoadExtensions([ 'ConfirmEdit', 'ConfirmEdit/QuestyCaptcha' ]);

   $wgCaptchaClass = 'QuestyCaptcha';

   # QuestyCaptcha questions:

       $wgCaptchaQuestions = [

           'How many fingers on one hand?' => [ 5, 'five' ],

       ];

       $wgMainCacheType = CACHE_ANYTHING;

       $wgCaptchaTriggers['createaccount'] = true;

Any guidance would be greatly appreciated!

Dinoguy1000 (talkcontribs)

It sounds like your wiki is configured to require all account registrations to be approved by an administrator/trusted user? ConfirmEdit/QuestyCaptcha may not have been tested in that type of environment, since no WMF wikis have such a setup.

SheldonBole (talkcontribs)

Hello Dinoguy1000, thanks for the suggestion. I am busy following up, as in I'm turning those settings off to see if I can get QuestyCaptcha to work, but have run into other, I hope unrelated, issues. So I'm sorting those issues before being able to test your suggestion. On Extension:ConfirmAccount it does specifically say:

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

However, I do understand from your suggestion you are specifically referring to QuestyCaptcha.

I have a few things I want to test... I'll be back.

SheldonBole (talkcontribs)

For anyone finding this thread, Extension:ConfirmEdit's QuestyCaptcha and Extension:ConfirmAccount don't play nicely!

When QuestyCaptcha's creataccount trigger is set to true, the question appears correctly on the account request form. However, incorrect answers to QuestyCaptcha have no effect and account requests are still submitted.


I have set $wgCaptchaTriggers['createaccount'] = false as the Captcha is not having any effect on account creations.


We decided to rather keep the account approval (through Extension:ConfirmAccount) and QuestyCaptcha functionality on the other Extension:ConfirmEdit's triggers. This has stopped fake accounts being created on our wiki at this stage.


For a brief period when I had:

$wgGroupPermissions['*']['createaccount'] = true; and

$wgCaptchaTriggers['createaccount'] = false;

We were inundated with fake account creations. Even though I had ConfirmAccount enabled. To solve this I set $wgGroupPermissions['*']['createaccount'] = false;. New users then need to "Request Account" through ConfirmAccount's functionality. This doesn't really affect user experience, but does stop bots creating fake accounts.

MyWikis-JeffreyWang (talkcontribs)

We are also encountering this issue. This is particularly problematic for us because we are still trying to prevent fake signup requests, as we need to keep our bounce rates down in order to stay on SES.

MyWikis-JeffreyWang (talkcontribs)
Reply to "QuestyCaptcha not preventing account creation"

What do you have in your visual CAPTCHA warehouse?

2
180.246.48.94 (talkcontribs)

Because this is straight out weird.

180.246.48.94 (talkcontribs)

The text reads "bakedbeams" before the Captcha expires the entry image.

Reply to "What do you have in your visual CAPTCHA warehouse?"
Costas Athan (talkcontribs)

Not a bug. I had enabled the CSP header (Manual:$wgCSPHeader/en) and I should add an exception for the hCaptcha scripts in order to load. I did it and now everything seems to work fine. At least the hCaptcha loads normally.


I am using MediaWiki 1.35.0.

I created an hCaptcha account and I enabled hCaptcha following these instructions: https://www.mediawiki.org/wiki/Extension:ConfirmEdit#hCaptcha (For added safety I basically load the keys from an external file, out of the webroot, as described here for MySQL passwords: https://www.mediawiki.org/wiki/Manual:Securing_database_passwords)

The problem is that the hCaptcha does not load. I get the text "To protect the wiki against automated account creation, we kindly ask you to solve the following hCaptcha:", but hCaptcha isn't available.

Am I missing something about its configuration?

HenriqueCrang (talkcontribs)

Does ConfirmEdit save a log of all the events when it shows a captcha? I'm interesting in looking for the user, the content and the captcha answer for each attempt. Is it possible?

Reply to "Log of CAPTCHA attempts"
Return to "ConfirmEdit" page.