Extension talk:ConfirmEdit/Archive 03

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.

Hello, I'm trying to use QuestyCaptcha for registration due to expensive spam bots.

The current plan is to use registration only with dynamic QuestyCaptcha (using a dynamic algorithm to generate key-value pairs. issuing with community bots. These will be one-use only, so it might look a bit rough).

But I had an idea: if badlogin or badloginperuser is triggered, I want to issue hCaptcha or Turnstile. Since registration should proceed smoothly, a badlogin would only happen if an account were being attacked by bots or something similar, just in case. However, it seems there’s no documentation on this. Is it not possible, or possible but lacking documentation?

Amended

there is an ortographic error in the file de-formal.json: "dass Sie um die Beantwortung einer Frage gebeten wirst." must be "dass Sie um die Beantwortung einer Frage gebeten werden." (the last word). Please change it if possible. Thank you. JPB

Vielen Dank für den Hinweis. Ich habe die Änderung vorgenommen, die in den nächsten Tagen eingespielt werden sollte. Grüße

Hi, am I the only experiencing recently bot attacks that were so far stopped by QuestyCaptcha ? I changed the question and the attacks started again the next day.

I guess there are now bots resorting to AI to guess the answers...

We've had a recent uptick on my own wiki as well. This isn't surprising; the endgame for QuestyCaptcha was always going to be some form of AI that was finally sophisticated enough to answer the questions you'd use for this. For right now, though, it still seems like the increase isn't too extreme.

Thanks for your feedback. I think we'll soon have to implement better antispam filters. But it seems there is no simple solution available right now.

Hi! We've been getting the same awful spam in our universitys wiki...

Has anyone been able to rid themselves of this?

No it's a nightmare... Apparently in my case they use the service "2captcha dot com" which uses clickworkers to constantly solve captcha. So many human energy wasted in such annoying and harmful ways...

Same. Anyone had any luck blocking these?

I'm trying the extension ConfirmAccount. I'm asking people willing to create an account to write a few words to confirm they're human. We'll see...

ConfirmEdit 1.6.0 MW 1.39.6 PHP 7.4.3 MYSQL 8.0.36

When registering a new account, I receive

[bd47ef227f5d4ce05b1a77e2] /wiki/Spezial:Benutzerkonto_anlegen Error: Call to undefined method User::getCanonicalName()

Backtrace:

from /var/www/test/mediawiki/extensions/ConfirmEdit/SimpleCaptcha/SimpleCaptcha.php(475)
#0 /var/www/test/mediawiki/extensions/ConfirmEdit/SimpleCaptcha/SimpleCaptcha.php(334): SimpleCaptcha->badLoginPerUserKey()
#1 /var/www/test/mediawiki/extensions/ConfirmEdit/includes/auth/CaptchaPreAuthenticationProvider.php(148): SimpleCaptcha->resetBadLoginCounter()
#2 /var/www/test/mediawiki/includes/auth/AuthManager.php(2620): CaptchaPreAuthenticationProvider->postAuthentication()
#3 /var/www/test/mediawiki/includes/auth/AuthManager.php(415): MediaWiki\Auth\AuthManager->callMethodOnProviders()
#4 /var/www/test/mediawiki/includes/specialpage/LoginSignupSpecialPage.php(344): MediaWiki\Auth\AuthManager->beginAuthentication()
#5 /var/www/test/mediawiki/includes/specialpage/SpecialPage.php(701): LoginSignupSpecialPage->execute()
#6 /var/www/test/mediawiki/includes/specialpage/SpecialPageFactory.php(1428): SpecialPage->run()
#7 /var/www/test/mediawiki/includes/MediaWiki.php(316): MediaWiki\SpecialPage\SpecialPageFactory->executePath()
#8 /var/www/test/mediawiki/includes/MediaWiki.php(904): MediaWiki->performRequest()
#9 /var/www/test/mediawiki/includes/MediaWiki.php(562): MediaWiki->main()
#10 /var/www/test/mediawiki/index.php(50): MediaWiki->run()
#11 /var/www/test/mediawiki/index.php(46): wfIndexMain()
#12 {main}

I am a little bit confused. The documentation states this extension needs MW >= 1.42.

Only the most recent version of an extension is documented, though exceptions are possible. Anyhow, you must use the version specific to the respective branch/version of MediaWiki. It should work with this version: REL1_39 (download link)

Ok, works with the above linked zip download. Thank you!

However, then it's the documentation that is incorrect. It says "This extension comes with MediaWiki 1.18 and above. Thus you do not have to download it again. However, you still need to follow the other instructions provided."

but obviously this is wrong.

Hmm, the version bundled with the tar of MediaWiki should have included the correct version of MediaWiki. Dunno what went wrong.

I tried configuring SimpleCaptcha by loading the extension and setting $wg...... variable. When I enabled the debug message, it said SimpleCaptcha class not defined. I have moved on to MathCapacha which worked. SimpleCaptcha may please be checked.

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 ?

Thank you L Andy, you have saved me. I was trying to solve this for 3 days.

Product	Version
MediaWiki	1.39.3
PHP	8.1.18 (apache2handler)
MySQL	5.7.41
ICU	67.1

Hi Iam facing issue when trying to edit any of the page in Mediawiki.

please suggest ?

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.