Extension talk:ConfirmEdit/Archive 01

The following discussion has been transferred from Meta-Wiki.
Any user names refer to users of that site, who are not necessarily users of MediaWiki.org (even if they share the same username).

Problem Installing PHP ERROR

When I try to install the extension it causes the entire wiki to fail and I get a blank screen MediaWiki: 1.6.10 PHP: 4.3.9 (apache2handler) MySQL: 4.1.20

the error message is

[client 79.181.107.14] PHP Warning: main(): URL file-access is disabled in the server configuration in

LocalSettings.php on line 132 [client 79.181.107.14] PHP Warning: main

(/extensions/ConfirmEdit/ConfirmEdit.php): failed to open stream: no suitable

wrapper could be found in LocalSettings.php on line 132 [client 79.181.107.14] PHP Fatal error: main(): Failed opening required

'/extensions/ConfirmEdit/ConfirmEdit.php'

in /home/sites/worker/worker_tests/wiki_dev/LocalSettings.php on line 132

Locale setup problem

How can I set english locale for ConfirmEdit?

When I setup ConfirmEdit r19995, then it works with messages like japanise.

Workaround

CofirmEdit seems to write messages in the language that is last defined in ConfirmEdit.i18n.php. Hence, I added the following line to the end of this file:

$wgConfirmEditMessages['last'] = $wgConfirmEditMessages['en'];

Now all messages are in English. I've tested this with MediaWiki 1.6.10.

However, this does not fix the original issue, that ConfirmEdit and MediaWiki use different locales. Any ideas?

13:58, 30 October 2007 (UTC)

It looks like yet another conflict between ConfigEdit version and MediaWiki version. Looking at http://svn.wikimedia.org/svnroot/mediawiki/branches/REL1_10/extensions/ConfirmEdit revision 27741, ConfigEdit.php, line 156-157, you can see that ConfigEdit tries to add all its i18n'ed messages to a cache. It tries to tell MediaWiki which messages are for which locale by using the second argument. But if you look at MediaWiki 1.6.10, includes/MessageCache.php, line 485, addMessages takes only 1 argument. I fixed this by having ConfirmEdit add only the current locale to the message cache:

function ceSetup() {
        # Add messages
        global $wgMessageCache, $wgConfirmEditMessages, $wgLanguageCode;
        $wgMessageCache->addMessages( $wgConfirmEditMessages[$wgLanguageCode] );

Debian Etch problems

Debian Stable (AKA Etch) uses MediaWiki 1.7.1 and adding this extension returns

Fatal error: Call to undefined function wfMemcKey() in /var/lib/mediawiki1.7/extensions/ConfirmEdit/ConfirmEdit.php on line 358

I think the compatibility with versions is out of date on the install page??

I upgraded to mediawiki1.10 1.10.2-1 and things work now. Do not use the Debian auto upgrade at this date (10/13/07) - has issues. Instead create a new LocalSettings.php via http://www.myserver.org/mediawiki/config/index.php Then run meld and see the differences between your old and new LocalSettings.php

Installing?

How do i install the ConfirmEdit extention?

--84.179.34.46 23:29, 21 February 2006 (UTC)

The installation directions are there, copy the files and include the declaration. --Kenny5 02:10, 12 April 2007 (UTC)

Patch for not matching any links

I noticed that it was not matching any links, so I added this patch: http://paulproteus.acm.jhu.edu/tmp/omg

I believe it's due to changes in the underlying MediaWiki.

-- Asheesh Laroia, 2006-11-24.

— Preceding unsigned comment added by 72.226.193.42 (talk • contribs) 20:49, 24 November 2006

Yes, it was a regression bug and was fixed in the 18349 revision of ConfirmEdit.php. Vocaro 11:04, 15 December 2006 (UTC)

I can't install ConfirmEdit

How I can install only ConfirmEdit? I don't see any links. Kirill

— Preceding unsigned comment added by 83.219.129.26 (talk • contribs) 09:14, 25 December 2006

Hmm... Have you read the page? If you want to have it installed on a Wikimedia project, open a bug at http://bugzilla.wikimedia.org --.anaconda 16:42, 25 December 2006 (UTC)

Sorry. I don't understand, what this extansionn do. I think that moderator can approve change articles. But I see - this simple check of work people, not spam-bot. :(

I tried installing ConfirmEdit as per the instructions on a Wikimedia 1.9.3 installation. However I end up with a blank page with no errors. commenting out the 'require_once' line in the localsettings file brings the site back to life. Any idea how to allow the site to show script errors so I can see what's going wrong? April 2, 2007. Todd

Never mind - forgot to install the internationalization file.

Special Pages Information

It would be nice to have some mention of how to create the Special Pages files for this extension, and perhaps a sample file.

skipcaptcha by IP address range?

Anyone know of a quick way to modify this extension to allow IPs in a specific range to skip the captcha? —Alxndr ^(t) 00:16, 14 February 2007 (UTC)

There's an IP whitelist in ConfirmEdit.php. Just look at the comments before $wgCaptchaWhitelistIP. Put this whitelist info into LocalSettings.php after the require_once(...) and you should be good to go. Michael Daly 18:48, 8 July 2007 (UTC)

ERROR

Warning: Cannot modify header information - headers already sent by (output started at /home/codev/public_html/en/w/extensions/ConfirmEdit/ConfirmEdit.i18n.php:516) in /home/codev/public_html/en/w/includes/WebResponse.php on line 9

Warning: Cannot modify header information - headers already sent by (output started at /home/codev/public_html/en/w/extensions/ConfirmEdit/ConfirmEdit.i18n.php:516) in /home/codev/public_html/en/w/includes/WebResponse.php on line 9

Warning: Cannot modify header information - headers already sent by (output started at /home/codev/public_html/en/w/extensions/ConfirmEdit/ConfirmEdit.i18n.php:516) in /home/codev/public_html/en/w/includes/WebResponse.php on line 9

Warning: Cannot modify header information - headers already sent by (output started at /home/codev/public_html/en/w/extensions/ConfirmEdit/ConfirmEdit.i18n.php:516) in /home/codev/public_html/en/w/includes/WebResponse.php on line 9

It works for me in 1.9.3. Try disabling all other extensions and see what happens. --Kenny5 02:08, 12 April 2007 (UTC)

End of content from meta.wikimedia.org.
Note that the above conversation may have been edited or added to since the transfer. If in doubt, check the edit history.

tested with wikimedia 1.9.3 and not displaying any captcha

thanks for checking... cedric walter from == http://wiki.waltercedric.com

It works for me, in 1.9.3. --Kenny5 02:12, 12 April 2007 (UTC)

I'm also not seeing any captcha in 1.9.3. I've tried accessing the .png files directly, and that works fine. Accessing them via the generated Special: URL doesn't, though. I get this error message instead:

The image “http://www.qualtrics.com/wiki/index.php?title=Special:Captcha/image&wpCaptchaId=405875869” cannot be displayed, because it contains errors.

ConfirmEdit is the only extension that's installed so far, and it's set up to use FancyCaptcha.

AHA! I think I've found the problem, at least for my site. Apache is applying mod_deflate when I request the image via the Special:Captcha URL, probably because the actual request is for a PHP script and not directly for an image. Now, I just need to find out how to turn off mod_deflate for image requests without turning it off for everything else...

Install question

I've been working on an upgrade from 1.4.7 to 1.6.10 (the best I can do without PHP5), and have run into a couple of things with this extension.

First, the captcha images I created don't render in the browser on signup. Here's example source:

<img src="/index.php?title=Special:Captcha/image&wpCaptchaId=2054738469" width="215" height="62" alt="" />

I'm having the same problem with images not being rendered. It looks like the Captcha special page is not created at all, but I still can't figure out why not.

I know the extension is seeing the images because if I change the path it gives an error about not finding them.

Second, the default language is Slovak (which is the last one in the FancyCaptcha.i18n.php source). Is there a quick variable I can change to fix this?

To fix the language displayed, move the desired language to the end of the FancyCaptcha.il8n.php file so it is the last one added to the array. For some reason (as you've discovered) the last language is displayed, despite locale settings.

Thanks

Captcha trigger for uploads?

Is there or can a trigger be created for when someone attempts to upload a file? I've had a few vandals replace images on my wiki and ConfirmEdit has definitely slowed them down (thank you!), but the captcha doesn't come up when you upload or replace an image file.

Doesn't work

The development version as of today just gives me this:

Parse error: syntax error, unexpected T_BOOLEAN_AND, expecting '(' in /home/pclos/public_html/docs/extensions/captcha/ConfirmEdit.php on line 308

Sy Ali 02:05, 14 May 2007 (UTC)

Placing empty parenthesis: "()" after each LoginForm::WRONGPASS seems to fix it:

< $retval = LoginForm::WRONG_PASS;

> $retval = LoginForm::WRONG_PASS();

Does Nothing

Installed the SVN version (as per the link given elsewhere here) for Wiki version 1.6.10, PHP4. The include line is in the LocalSettings file, I've installed ExtensionFunctions.php in the /extensions directory, the ConfirmEdit files are in a ConfirmEdit directory.

No errors displayed or logged, no captcha displayed, accepts edits for non-logged in users without complaint. It does absolutely nothing.

Got same problem

Confirmed this does nothing on v 1.16. No errors generated. Confirmed it is installed.

T_BOOLEAN_AND

This problem still exists as of July 1st 2007.

• as of 12 June, I also get the error:
  • Parse error: syntax error, unexpected T_BOOLEAN_AND, expecting '(' in /home/wiki/public_html/w/extensions/ConfirmEdit/ConfirmEdit.php on line 320
  • Aussiepete 05:58, 12 June 2007 (UTC)

wfMemcKey

After downloading and installing latest version on MW 1.7.3, Special:Userlogin returns:

Fatal error: Call to undefined function wfMemcKey() in /web/domain.org/extensions/ConfirmEdit/ConfirmEdit.php on line 348

--MatthewBurton 04:41, 4 June 2007 (UTC)

any solution for this?

Mdale 18:34, 11 June 2007 (UTC)

Installed an older version. It uses arithmetic problems instead of captchas, but it's blocked all spam so far. The language in the PHP files reflect captchas, not math, so be sure to change it so your users aren't confused. - MatthewBurton 04:34, 17 June 2007 (UTC)

This is probably due to the script trying to use $wgMemc for storing bad login info. Usually, $wgCaptchaStorageClass decides if cookies or $wgMemc is used for storage, but a bug in the script makes it attempt to use $wgMemc even when you've chosen cookies for storage. I solved this crudely by commenting out all things regarding bad login counting. - Ymgve

new $wgCaptchaClass

My wiki (1.6.6) crashes on this line : $wgCaptcha = new $wgCaptchaClass();

Any ideas? Am I missing additional files? If so, please state that one has to use this or that version SPECIFICALLY. I am at a loss here.

Mr.Mouse

same but different..... new $wgCaptchaClass

Mr. Mouse, I'm having the same trouble with My wiki (1.12.0) it is also not working at : $wgCaptcha = new $wgCaptchaClass(); ...this is line 9 I'm just waiting for a spam attack! -Will --Willjermuk 15:05, 21 June 2008 (UTC)

Right is there another place can place this post to get some help or suggestions on this issue, haven't heard from anyone in a week. Thanks Will --Willjermuk 14:55, 28 June 2008 (UTC)

Another install question

The extension kills the site when I plug it into LocalSettings.php. I workaround that by replacing $IP with the real address, but the extension doesn't work. Site's called videoville.org, running on MediaWiki 1.6.10. Any help is totally rad. --24.208.181.227 21:15, 7 July 2007 (UTC)

I get the same result. MediaWiki 1.6.10, PHP 4.3.9, MSQL 4.1.20. It looks like one of the early install problems posts rectified it simply by making sure the internationalization file was present. Both files have always been present for me. I've tried numerous mods to the scripts with no luck. Bummer, looked like and awesome extension.--129.74.153.198 19:14, 23 August 2007 (UTC)

$IP should be your install path and not the IP address. By dumping an IP address in there you just causing the extension to fail to load. J.smith 19:49, 13 December 2007 (UTC)

captcha image generation

Does anyone have any better captcha image generation script that works with FancyCaptcha or know how to modify the image generation on captcha.py? The images I generated are too unreadable to be useful. See http://www.zuul.org/~zuul/image_ff988f48_3e1f52eb9fe90987.png I'm using a simple sans serif truetype font with python-2.4.3p0 and PIL py-Imaging-1.1.5p0 on OpenBSD 4.0. Please respond to me at http://en.wikipedia.org/User:Sborsody. Thanks.

Well it looks like you should use a bold font when generating the images. I tried Arial Black and other bold like Tahoma Bold and it looks a lot better. --SBorsody

The best Captcha I've seen involves identifying pictures instead of letters/numbers. A fire truck, a football, a duck, etc. Basic images that any human could recognize. As far as I know, no bot has cracked it yet. 208.201.146.137 18:35, 27 September 2007 (UTC)

Suggestion: Make number of links configurable

Hi, would be a nice feature to be able to configure the number of links in an edit needed for the captcha to be thrown. So when I add only one link I don't get harassed by the captcha. ;-)

I might look into it myself when I have more time... --Matsch 19:25, 23 August 2007 (UTC)

Conflicting with SpamBlacklist Extension

Hi, it seems this extension is conflicting with the SpamBlacklist Extension (link). On creation of a new page (where a captcha is thrown) i get the following error:

Warning: Missing argument 4 for wfspamblacklistvalidate() in /home/www/web125/html/rockinchina/wiki/extensions/SpamBlackList/SpamBlacklist.php on line 67

• MediaWiki: 1.6.8, PHP: 4.4.6

Cross posting to: Extension_talk:SpamBlacklist -- Matsch 20:07, 23 August 2007 (UTC)

Another Captcha option?

My host says I have python available, but I can't dump files into the directory myself. They also said "the server supports the CAPTCHA php pear modules. You can use these modules to generate CAPTCHA." Is there a way to use what's already there with MediaWiki?--Azurite 05:06, 4 September 2007 (UTC)

If you can, use reCAPTCHA. It doesn't require any python libraries. --MZMcBride 00:47, 18 September 2007 (UTC)

Suggestion: Captcha for new IPs

This extension has been phenomenally successful in stopping spam on our site, but there's still one kind of bot that gets through. It doesn't add spam, all it does is insert nonsense words onto the beginnings of hundreds of pages, changing IPs regularly to avoid blocks. It's obviously a bot gone haywire, but I've come up with a possible solution to stop it. Have an option that requires Captchas for the first 5 edits from any new IPs. Include a note on the page saying "This will only be required for your first five edits", so as to avoid scaring away legit editors. This would stop about 99% of the junk edits on our site, and I know this bot affects lots of other wikis as well. I'm useless at PHP, so I wouldn't know where to begin with this, but I'm sure it can't be that complicated to set up for someone who knows what they're doing. A good idea? 70.119.42.36 17:14, 9 November 2007 (UTC)

undefined function wfLoadExtensionMessages

When attempting to install on a 1.10.1 wiki version, we're getting the following error:

PHP Fatal error: Call to undefined function wfLoadExtensionMessages() in /opt/****/httpd/****.org/html/extensions/ConfirmEdit/ConfirmEdit_body.php on line 9

I haven't been able to find any references to this specific error and was wondering if anyone had any advice? Thanks in advance.

I have got the same problem trying to install the SimpleCaptcha Version. My current impression is that SimpleCaptcha is not supported and it should be used together with te FancyCaptcha addon. I found the following problems:

1. You need a third file ConfirmEdit_body.php and require_once it in the LocalSettings.php. You can get this file using the given svn checkout.
2. My version of PHP complains about a missing "ConfirmEditHooks::confirmEdit". The cause seems to be that the Hook-Mechanism interprets this as a function name containing colons rather than static function confirmEdit from class ConfirmEditHooks. The $wgHooks assignment should probably be in the form array('ConfirmEditHooks', name of the static function) to conform with PHPs callback pseudotype.
3. After commenting out the calls to wfLoadExtensionMessages SimpleCaptcha seemed to work except that the MediaWiki software showed something like names of the message handles rather than the message contents contained in ConfirmEdit.i18n.php. I am still trying to find some way to display these contents.

--09:20, 17 November 2007 (UTC)~~

My guess is that you are using the latest version of this extension, which might be using functions, like wfLoadExtensionMessages(), which did not exist in 1.10, but where introduced in 1.11 or even only 1.12alpha. The 1.10 branch of ConfirmEdit can be found here: http://svn.wikimedia.org/svnroot/mediawiki/branches/REL1_10/extensions/ConfirmEdit/ -- Duesentrieb ⇌ 15:53, 17 November 2007 (UTC)

Thank you for the tip - version mismatch seems to be the actual problem. I spent a lot of time analyzing problems related to not working combinations of Mediwiki-Software and ConfirmEdit versions. I think to have found an error like 11082 in includes/Hooks.php, line 106, MediaWiki 1.9.3. Therefore I put a table summaring my experience and hoping that it will fill up.

-- Albrecht Müller 18:55, 18 November 2007 (UTC)

MediaWiki	ConfirmEdit	Description
1.10.1	Current version from main page	Complains about missing wfLoadExtensionMessages function
1.9.3 from 20 Feb 2007?	REL1_10	SimpleCaptcha seems to work. FancyCaptcha shows not captcha pictures. MathCaptcha not tested due to lack of TeX support.
	Current version from main page	SimpleCaptcha does not work (requires additional ConfirmEdit_body.php file, complains about missing wfLoadExtensionMessages function. FancyCaptcha not tried MathCaptcha not tested due to lack of TeX support.

"warning First argumented is expected to be a valid callback..."

I've attempted to add the latest ConfirmEdit (rev 27622) to a mediawiki 1.6.10 (which I'm limited to as host, sf.net, runs PHP 4.3.10). However, I now get this warning on the top of some pages (those that use the extension, it seems):

Warning: call_user_func_array(): First argumented is expected to be a valid callback, 'ConfirmEditHooks::injectUserLogin' was given in mediawiki-1.6.10/includes/Hooks.php on line 114

...and no captcha. I'm not familiar with PHP, so this stumps me. Any ideas?

john --19-11-2007

Ah, I missed the note about PHP4 in the main page. Anyone know precisely which version in SVN I should try using?

john --20-11-2007

OK, some updates and version bisecting later, I can tell you the last vanilla version to work with PHP4 is SVN rev 21970. Useful for those people stuck on a PHP4 host (sourceforge, I'm looking at you)

john --22-11-2007

I am having this same problem with the same specs as you. Thanks for the rev #. --HenryWS 04:33, 26 November 2007 (UTC)

My Mediawiki says on Special:Version - MediaWiki: 1.6.7 and PHP: 5.1.6-1 (cgi-fcgi) -, however, I get the same error as you. -- JanCK 10:00, 19 September 2008 (UTC)

I've now also installed rev 21970. It works. But I needed to patch the i18n file with the workaround described here: Extension talk:ConfirmEdit#Locale setup problem and it took me 2minutes (which is more than I expected) to find the link: http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/ConfirmEdit/?pathrev=21970 to rev 21970 and I still don't know how to download all of the files (for example as a gz) instead of downloading every file on its own. -- JanCK 10:35, 19 September 2008 (UTC)

Invalid argument supplied for foreach() in/home/stephen/public_html/usmoi/wiki/includes/MessageCache.php on line486

This is the error I am getting on my wiki. Here is my ConfirmEdit.php. I am using MW 1.6.10, PHP 4.4.7. Thanks. --HenryWS 20:46, 27 November 2007 (UTC).

Blank screen after installing confirmedit

I installed confirmedit, but now I can't make any updates anymore. After I press save on any edit page I'm getting a blank page. No error message whatsoever. I'm using mediawiki 1.11 and the newest cofirmedit plugin (jan 2008). Does anybody have any idea where to look?

Ronald - 06-01-2008

Same...

Thomas -05.02.08

Are there any screenshots available?

It would be nice to have a look on this captcha implementation before you decide to install it.

It is the ConfirmEdit standalone. One Shoot ConfirmEdit --Neoshinji 06:45, 2 January 2009 (UTC)

Can't find file/Don't Understand Directions

Where am I supposed to find the fonts files and word files? I don't see them in the Imaging folder I downloaded.

Also, I'm new to python - when you say run...

python captcha.py --font=/usr/share/fonts/truetype/freefont/FreeSans.ttf 
--wordlist=/usr/share/dict/words --key=FOO --output=../../../captcha --count=100

... do you just mean to input the correct values into captcha.py and save it?

The fonts files and word list are not packaged in this extension. Your system should already have fonts, and you need to create the word list yourself.

And when it says to run those commands, it does not mean to add those lines to captcha.py. It means to run those commands from the command line prompt.

—Lowellian (talk) 14:38, 19 June 2010 (UTC)

it works:-)

hallo everyone, i've installed the extension. but there is nothing to see.. http://ol-wiki.de is the wiki.

here you can try it: http://ol-wiki.de/index.php?title=Testseite

this is mediawiki 1.6.6.

i've installed it as i should. (upload the files and include it in the localsettings)

please help me:-) 84.189.126.205 21:26, 23 March 2008 (UTC)

Works fine for me - when I try to add a URL to thatpage, it triggers. If you want it on all edits, set $wgCaptchaTriggers['edit'] = true; as the manual sais. -- Duesentrieb ⇌ 09:27, 24 March 2008 (UTC)

ups^^. my english is not the best. so i thought always there is the quastion. not only when i'm posting urls. so thank u very much for the help and the extension!! 84.189.110.25 20:53, 24 March 2008 (UTC)

Place captcha on first edit page

Hello, I want to use this extension on every edit, so it doesn't matter what the user typed in. Therefore I would like to have the captcha already on the first edit page right after clicking on edit, maybe just above the save button. Is there an option for this? --Jorges 17:20, 22 April 2008 (UTC)

• I'd also like to know this. --Naught101 00:35, 6 November 2008 (UTC)

Captcha anonymous edits

I had a bot posting quite embarrassing stuff - no links but just very inappropriate language. So I've added captcha on all edit's by anonymous users.

$wgCaptchaTriggers['anonymous'] = true;
 ....
function shouldCheck( &$editPage, $newtext, $section ) {
.....
         if( $this->captchaTriggers( $editPage, 'anonymous')) {
                       if ($wgUser->isLoggedIn() ) {
                               return false;
                               wfDebug( "ConfirmEdit: user is logged in, skipping captcha\n" );
                       }
                       wfDebug( "ConfirmEdit: anonymous user trying to edit - showing captcha \n" );
                       return true;
               }

Move the Link

When the confirmedit is triggered, we only do it for external links, the more info link is causing problems in the sentences: "Your edit includes new external links. To help protect against automated spam, please enter the words that appear below in the box (more info)". We are using the simple algebra captcha and we want to stay with that. But on some resolutions when the page is still loading, the user clicks on the box but the toolbar then loads and the click goes to the more info link instead. Some browsers don't save POSTDATA and so they have lost all their changes. Is it at all possible to move the link to another part in these sentences or to remove the link altogether?--Mjr162006 16:51, 21 June 2008 (UTC)

Is anyone going to answer?--Mjr162006 13:20, 25 June 2008 (UTC)

You could alter the message to make it longer or shorter, so the link would be less likely to appear right at that spot. You can find all editable UI messages at Special:Allmessages; it should be MediaWiki:Captcha-addurl or a related one specified by the captcha variant you're using. --brion 19:48, 4 July 2008 (UTC)

Thanks a lot. We've got it fixed now.--Mjr162006 21:26, 5 July 2008 (UTC)

Error logged when ConfirmEdit Hook is called

Hi,

I am using mediawiki 1.6.8 and ConfirmEdit trunk-r37988 version. I have created the images as explained in the page. However, when ConfirmEdit is called following error is logged and image doesn't come.

PHP Warning: call_user_func_array() [<a href='function.call-user-func-array'>function.call-user-func-array</a>]: First argument is expected to be a valid callback, 'ConfirmEditHooks::injectUserCreate'

Please help

Thanks, Mohan Cheema

Redeclaration error / on MediaWiki 1.12.0 - including solution

I tried to install ConfirmEdit on MediaWiki 1.12.0, and got problem.

Error message was like this(not exatly same). => redeclare the class SimpleCaptcha

I solved this problem by adding an "if" statement at every declaration of classes, like below.

(class declarations are in "ConfirmEdit_body.php")

if(!class_exists("SimpleCaptcha")) {
class SimpleCaptcha {
...
}
}


Plus, a function "confirmEditMerged()" is needed for editing page, so I added this function that just returns true on SimpleCaptcha(and whatever captcha class you want to use) class.

Now my wiki works well with working above.

- inornate

solution?

I had that problem on 15.x when trying to use MathCaptcha but realized that you need to still include ConfirmEdit to get those essential class definitions (SimpleCaptcha), otherwise the extended captcha you use wont load.

require_once( "$IP/extensions/ConfirmEdit/ConfirmEdit.php"); require_once( "$IP/extensions/ConfirmEdit/MathCaptcha.php"); $wgCaptchaClass = 'MathCaptcha';

daniel

wgCaptchaBadLoginExpiration Not Working?

Hi, I am using Mediawiki 1.13.2 with ConfimEdit, badlogin set to True and CACHE_DB enabled. I am getting the expected Captcha prompt on user login failures but I have the wgCaptchaBadLoginExpiration set to 9999 * 60, and the login prompt (with Captcha prompt) still immediately returns to the screen upon failure. I am expecting it to delay to 9999*60 seconds. What am I missing? Thanks!

You may be misunderstanding $wgCaptchaBadLoginExpiration. Until $wgCaptchaBadLoginExpiration seconds have passed after $wgCaptchaBadLoginAttempts from an IP, that IP will have not be able to log in without solving a CAPTCHA. —Emufarmers^(T|C) 21:11, 6 November 2008 (UTC)

This is very helpful thanks. I'm trying to prevent bots potentially brute force attacking my mediawiki user accounts. Adding Captcha's will help prevent attacks, but I would also like to automatically ban IP's that fail to login a certain amount of times. Can this extension help with that or do you have any idea of any that could? Thanks! --Timvaverchak 15:33, 12 November 2008 (UTC)

Bad login

Does Bad login detection only work if caching is enabled? It doesnt work on my wiki. --Kenny5 15:10, 17 December 2008 (UTC)