Extension talk:ConfirmEdit

About this board

Archives 

ConfirmEdit crashes with SimpleCaptcha

4
2003:C2:3F21:FD00:134:BD68:4409:6542 (talkcontribs)

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.

Kghbln (talkcontribs)

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)

2003:C2:3F21:FD00:8929:33DC:DD0E:EA69 (talkcontribs)

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.

Kghbln (talkcontribs)

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

Reply to "ConfirmEdit crashes with SimpleCaptcha"

SimpleCaptcha not working?

1
2401:4900:1C68:161D:4C4C:A9CF:EEA6:606C (talkcontribs)

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.

Reply to "SimpleCaptcha not working?"

reCAPTCHA noCAPTCHA failing

7
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)
37.111.194.35 (talkcontribs)

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

Reply to "reCAPTCHA noCAPTCHA failing"

Fatal error: Declaration of MWCallbackStream::write($string) must be compatible with Psr\Http\Message\StreamInterface::write(string $string): int in /var/www/html/includes/http/MWCallbackStream.php on line 49

1
Pooja2425 (talkcontribs)
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 ?

Reply to "Fatal error: Declaration of MWCallbackStream::write($string) must be compatible with Psr\Http\Message\StreamInterface::write(string $string): int in /var/www/html/includes/http/MWCallbackStream.php on line 49"

hCaptcha is proving itself vulnerable to "brute-force" spam attacks

2
204.237.89.128 (talkcontribs)
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.

204.237.89.128 (talkcontribs)

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)

Reply to "hCaptcha is proving itself vulnerable to "brute-force" spam attacks"

Does hCaptcha work with visualeditor?

2
Smallketchup82 (talkcontribs)

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

Ryoya3 (talkcontribs)

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.

Reply to "Does hCaptcha work with visualeditor?"
ValerioBoz-WMCH (talkcontribs)

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

ValerioBoz-WMCH (talkcontribs)

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.

Reply to "API Documentation"

QuestyCaptcha and ConfirmAccount do not work

5
Marx.FelipeForte (talkcontribs)

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

Marx.FelipeForte (talkcontribs)

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

2601:4C1:4001:6230:4DD3:477A:5FC:8701 (talkcontribs)

I have the same problem.

2601:4C1:4001:6230:4DD3:477A:5FC:8701 (talkcontribs)

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

Marx.FelipeForte (talkcontribs)

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

Reply to "QuestyCaptcha and ConfirmAccount do not work"
Uvas magicas (talkcontribs)

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

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?"
Return to "ConfirmEdit" page.