Extension talk:ConfirmEdit/2020

Problem with Confirm edit for 1.34

Hello

I am trying to use ConfirmEdit with Recaptacha but i get an error at the top of the page when i enable it, do anyone know why? i have the latest version of the extension and i am running Mediawiki 1.34. the error goes away when i dissable the extension.

ERROR:

Deprecated: Use of Using $ceAllowConfirmedEmail is deprecated, please migrate to $wgAllowConfirmedEmail as a replacement. is deprecated. [Called from require_once in /includes/Setup.php at line 906] in /includes/debug/MWDebug.php on line 333

LOCAL SETTINGS FILE

#Recaptacha

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

$wgCaptchaClass = 'ReCaptchaNoCaptcha';

$wgReCaptchaSiteKey = '';

$wgReCaptchaSecretKey = ''; 151.177.171.222 (talk) 14:54, 23 February 2020 (UTC)

Does your site use visual editor with which ReCatcha is not compatible? TiltedCerebellum (talk) 09:59, 30 June 2020 (UTC)

ConfirmEdit/QuestyCaptcha causing 500 error.

I have not had any issues in the past with any ConfirmEdit setup. I have had QuestyCaptcha set up on a mediawiki before. However, setting up Confirmedit and questycaptcha per the file, it gives me a 500 error.

173.184.192.53 (talk) 15:30, 29 March 2020 (UTC)

I was also receiving a 500 error. I am using MediaWiki 1.34 and was using require_once for QuestyCaptcha. When I removed this and added wfLoadExtensions my page loaded as expected.

This is explained at Extension:ConfirmEdit as follows:

// If your MediaWiki version is 1.25 or higher, use this line:

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

// Else use these lines:

require_once "$IP/extensions/ConfirmEdit/ConfirmEdit.php";

require_once "$IP/extensions/ConfirmEdit/QuestyCaptcha.php"; SheldonBole (talk) 12:54, 16 April 2020 (UTC)

I also found the following errors

[Sun Mar 29 15:21:56.553998 2020] [php7:warn] [pid 10690] [client 46.229.168.129:4538] PHP Warning:  mt_rand(): max(-1) is smaller than min(0) in /var/www/v5homebrew.com/public_html/mw/extensions/ConfirmEdit/QuestyCaptcha/includes/QuestyCaptcha.php on line 61

[Sun Mar 29 15:21:56.554088 2020] [php7:notice] [pid 10690] [client 46.229.168.129:4538] PHP Notice:  Undefined offset: 0 in /var/www/v5homebrew.com/public_html/mw/extensions/ConfirmEdit/QuestyCaptcha/includes/QuestyCaptcha.php on line 61

[Sun Mar 29 15:24:49.180120 2020] [php7:emerg] [pid 19004] [client 207.46.13.219:2281] PHP Parse error:  syntax error, unexpected 's' (T_STRING), expecting ']' in /var/www/v5homebrew.com/public_html/mw/LocalSettings.php on line 216

Line 216 is one of the questions for QuestyCaptcha. 173.184.192.53 (talk) 15:46, 29 March 2020 (UTC)

I figured it out. There were some characters that were trying to be parsed that needed to be escaped. 173.184.192.53 (talk) 16:03, 29 March 2020 (UTC)

QuestyCaptcha not preventing account creation

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! SheldonBole (talk) 22:44, 21 April 2020 (UTC)

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. 「ディノ奴千？！」^{☎ Dinoguy1000} 04:18, 22 April 2020 (UTC)

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 (talk) 13:09, 22 April 2020 (UTC)

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. SheldonBole (talk) 10:32, 28 April 2020 (UTC)

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. Jeffrey Wang 17:40, 25 February 2021 (UTC)

Update, this task hasn't been worked on in 3 years. https://phabricator.wikimedia.org/T168783 Jeffrey Wang 17:52, 25 February 2021 (UTC)

FancyCaptcha "pool.py error" generating Captcha images

Having issues generating captcha images, please help!

Current setup:

Python 2.7.18

Python Imaging Library 1.1.7 for Python 2.7 (Windows Only)

Error below:

C:\Python27>python.exe C:\Ex\captcha.py --font C:\Ex\FreeSans.ttf --wordlist C:\Ex\words.txt --key=Foo --blacklist C:\Ex\blacklist.txt --output C:\Ex\ --count=20

Generating 20 CAPTCHA images separated in 20 image(s) per chunk run by 1 threads...

Traceback (most recent call last):

  File "C:\Ex\captcha.py", line 298, in <module>

    p.map(run_in_thread, data)

  File "C:\Python27\lib\multiprocessing\pool.py", line 253, in map

    return self.map_async(func, iterable, chunksize).get()

  File "C:\Python27\lib\multiprocessing\pool.py", line 572, in get

    raise self._value

NameError: global name 'verbose' is not defined

Dthrevan (talk) 22:33, 6 May 2020 (UTC)

anyone??? Dthrevan (talk) 09:25, 7 May 2020 (UTC)

Same problem here. Need help. Thanks. Ulrich C. Thiess (talk) 14:58, 16 July 2020 (UTC)

QuestyCaptcha

By default, in which cases QuestyCaptcha asks question while editing/adding an articles and when not asks? Does it depend on email confirmation?

Farvardyn (talk) 10:36, 17 May 2020 (UTC)

Defaults for ConfirmEdit are listed on its page; QuestyCaptcha uses these defaults. In particular, captchas are by default shown to everyone except for bots and admins, any time a new URL is added to a page, an account is being created, or a login fails. See the section I linked for details on how to customize this setup for your wiki. 「ディノ奴千？！」^{☎ Dinoguy1000} 13:26, 17 May 2020 (UTC)

Captcha is not shown for login failures

I have added this code to Localsettings.php:

2409:4043:194:CE4A:18E0:AF1B:B5C:9BAF (talk) 10:46, 18 June 2020 (UTC)

I have added this code to Localsettings.php:

$wgCaptchaTriggers['badlogin'] = true;

However it doesn't show captcha question when I try to login with bad username or password.

It shows well for creating new acccount, so setup looks good.

Please suggest what should be done to fix.

Thanks,

Vikas 2409:4043:194:CE4A:18E0:AF1B:B5C:9BAF (talk) 10:47, 18 June 2020 (UTC)

FYI: Known issue with Extension:MobileFrontEnd: Captcha on sign-up page is not working/shown/reply not saved

See https://www.mediawiki.org/wiki/Extension%20talk%3AMobileFrontend/2019#h-Captcha-2019-12-30T22%3A42%3A00.000Z and https://phabricator.wikimedia.org/T248024 CayceP (talk) 20:01, 23 July 2020 (UTC)

Log of CAPTCHA attempts

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? HenriqueCrang (talk) 18:27, 14 September 2020 (UTC)

hCaptcha does not load

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

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? Costas Athan (talk) 07:04, 26 September 2020 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

What do you have in your visual CAPTCHA warehouse?

Because this is straight out weird. 180.246.48.94 (talk) 05:20, 25 October 2020 (UTC)

The text reads "bakedbeams" before the Captcha expires the entry image. 180.246.48.94 (talk) 05:23, 25 October 2020 (UTC)