Extension talk:ConfirmEdit

About this board

Archives 

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 by MyWikis-JeffreyWang

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"

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

1
CayceP (talkcontribs)
Reply to "FYI: Known issue with Extension:MobileFrontEnd: Captcha on sign-up page is not working/shown/reply not saved"

FancyCaptcha "pool.py error" generating Captcha images

3
Dthrevan (talkcontribs)

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

anyone???

Ulrich C. Thiess (talkcontribs)

Same problem here. Need help. Thanks.

Reply to "FancyCaptcha "pool.py error" generating Captcha images"
Return to "ConfirmEdit" page.