Extension talk:ConfirmEdit

Archives

2006 to 2008 2008 to 2011

Previous page history was archived for backup purposes at Extension talk:ConfirmEdit/LQT Archive 1 on 2015-07-10.

hCaptcha looks a lot like reCaptcha, but is newer and less-widely used. Cloudflare is one provider which switched from reCaptcha to hCaptcha, for example. It is not impossible to get bad data past hCaptcha - presumably by brute force attacks which can easily push your site above the one million hits per month limit for hCaptcha's "free" plan. This has been an issue since at least mid-2022. At that point, you will be approached in e-mail by hCaptcha marketers attempting to sell a very expensive "enterprise" version of the service, right around the time that you're dealing with increasing numbers of spam posts making their way past the blocks. That said, the majority of automated "spambot" posts will be blocked by hCaptcha; far less rubbish gets past hCaptcha than past reCaptcha, given that the latter's widespread adoption has made it the tool against which most of the spammers now appear to be testing their wares. As most of the "brute force" attacks seem to be coming from a long list of known problem IPs (the least-expensive cleantalk.org blacklist has about 10,000 records of spam records with frequency >= 200, for instance) it's probably best to use other means to block known-bad IPs from accessing your site at all, sending only whats left through hCaptcha. Otherwise, spammers will keep trying random responses until a small fraction of the spam gets through. The article does need to indicate that, while a bit more effective than reCaptcha, hCaptcha is vulnerable to determined attempts to get bad data past - the same as everything else. It's one tool in the toolbox, but it's not a panacea.

Actually, it's been going on a bit longer than that. I'm seeing spam posts with mid-2021 dates and (hCaptcha) in the edit comment, so apparently the spammers already were testing against hCaptcha.

Most of the brute-force attacks seem to be coming from IPs which are already one one or more of the real-time blacklists, so firewalling out the known-bad traffic first, then using CAPTCHA to sort what's left is likely best. Otherwise, what's to stop the spammers from hitting your server with two or three million attempts per month, which will exceed hCaptcha's limits for non-commercial use and which will also severely degrade operation of your server for human users. 204.237.89.128 21:46, 27 April 2023 (UTC)

The config docs say that recaptcha doesn’t work with visualeditor, I was wondering if this is the same with hCaptcha.

Currently, Recaptcha works in visualeditor, so perhaps hCaptcha will also work.

However, both hCaptcha/Recaptcha do not work in the Mobile Source Editor or DiscussionTools.

It's not clear to me how an API client should interact with this anti-spam component.

For example, when editing, this exception can be raised:

{"edit":{"captcha":{"type":"image","mime":"image\/png","id":"123","url":"\/w\/index.php?title=Special:Captcha\/image&wpCaptchaId=123"},"result":"Failure"}}

What to do next?

If I understand it, I would like to improve the documentation. Thanks folks

I've made some frontend tests and it seems to me that you have to submit wpCaptchaWord with the value of the captcha and wpCaptchaId with the ID of the captcha, but I'm still unsure if it's just OK to do the same via the standard edit API.

When using QuestyCaptcha along with ConfirmAccount, the prompt does appear, but any (incorrect) answer is accepted. What's the point?

Also tested with hCaptcha, and it still doesn't prevent account requests. Tested with different IPs and devices.

I have the same problem.

try to use the latest ConfirmAccount. build on Nov 4. After update, and restart my computer. it is working now.

Thank you, I've done exactly that, but I'm now using hCaptcha.

the option for now is the patch: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ConfirmEdit/+/539679/

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

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?

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?

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

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?

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

should i pass my website URL e.g(https://google.com) in the URL variable ?

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

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).

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?

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).

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

];

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.

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

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.

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.

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.

Hi All

I have same problem.

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

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;

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).

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).