Extension talk:ConfirmEdit
 Archives |
Contents
I have editing disabled for anons and would like to use MathCaptcha as default but QuestyCaptcha on account creation. Is there a solution?
Copy ConfirmEditHooks.php to ConfirmEditQuestyHooks.php, and edit the following:
class ConfirmEditHookstoclass ConfirmEditQuestyHooks- Replace the function getInstance() with:
static function getInstance() {
static $captcha = false;
if ( !$captcha ) {
$captcha = new QuestyCaptcha;
}
return $captcha;
}
- Remove the line
class CaptchaSpecialPage extends UnlistedSpecialPage {and everything below - In ConfirmEdit.php change the hooks you wish to be handled with QuestyCaptcha to ConfirmEditQuestyHooks (where it says 'ConfirmEditHooks::...' change to 'ConfirmEditQuestyHooks::...'). In your case, seem to be UserCreateForm and AbortNewAccount
I have Mediawiki 1.18 and it came with a ConfirmEdit extension. Adding any of the captchas though doesn't work. The Captcha doesn't show up at all. I've tried SimpleCaptcha, FancyCaptcha, MathCaptcha, etc. Nothing shows up when trying to edit a page.
Note: I'm using a regular account when testing the edit.
Follow the instructions on Extension:ConfirmEdit
I use trunk version of this extention and MW 1.18. When I click Log in / create account I recieave fatal error:
Fatal error: Call to undefined method WebRequest::getIP() in /srv/http/wiki/extensions/ConfirmEdit/Captcha.php on line 202
Try the latest version of ConfirmEdit
I use trunk version from SVN (last update at 2011-12-17).
You need to use the REL1_18 branch for both your main MW install and this extension. You can fix this by going to your ConfirmEdit directory and running:
svn switch http://svn.wikimedia.org/svnroot/mediawiki/branches/REL1_18/extensions/ConfirmEdit
Apparently, the change with getIP() hasn't been propagated to the REL1_18 branch.
Problem appears since r106097.
PHP Fatal error: Class 'HTMLFormField' not found in /var/www/vhosts/.../httpdocs/extensions/ConfirmEdit/HTMLCaptchaField.php on line 22
While using
require_once( "$IP/extensions/ConfirmEdit/ConfirmEdit.php" ); require_once( "$IP/extensions/ConfirmEdit/ReCaptcha.php");
there is an error message is my severs error_log
PHP Fatal error: Class 'HTMLFormField' not found in /var/www/vhosts/berghapedia.nl/httpdocs/extensions/ConfirmEdit/HTMLCaptchaField.php on line 22
What is the problem?
Regards, GW
You're probably using an older version of MediaWiki, that's not supported by the latest version of ConfirmEdit any more.
Then, why does the Extension page state the current release of ConfirmEdit supports MW 1.11 and later? I'm having the same problem, on a MW 1.15-based system.
ConfirmEdit results in Fatal Error. I am using 1.18 and the 1.18 version of the extention.
Fatal error: Call to a member function addMessages() on a non-object in /homepages/2/d276811108/htdocs/w/extensions/recaptcha/ConfirmEdit.php on line 172
Any clue what is going on? For now I will have to disable the extension.
Enable setting of $wgReCaptchaPublicKey and $wgReCaptchaPrivateKey before including ConfirmEdit
With the current SVN revision of ConfirmEdit, if you set any of the key variables ('wgReCaptchaPublicKey', 'wgReCaptchaPrivateKey', 'recaptcha_public_key', and 'recaptcha_private_key') before including ReCaptcha.php, they are overwritten and set to an empty string, causing ReCaptcha to cause an error. I have created a patch (below and http://blucoders.net/wiki/images/7/79/ConfirmEdit-ReCaptcha-fix.diff) that checks to see if they are set or not before initializing them to a blank string.
Index: ReCaptcha.php
===================================================================
--- ReCaptcha.php (revision 107720)
+++ ReCaptcha.php (working copy)
@@ -22,11 +22,10 @@
require_once( 'recaptchalib.php' );
// Set these in LocalSettings.php
-$wgReCaptchaPublicKey = '';
-$wgReCaptchaPrivateKey = '';
-// For backwards compatibility
-$recaptcha_public_key = '';
-$recaptcha_private_key = '';
+// The last two are for backwards compatibility
+$blank_vars = array('wgReCaptchaPublicKey', 'wgReCaptchaPrivateKey', 'recaptcha_public_key', 'recaptcha_private_key');
+foreach ($blank_vars as $varname)
+ if (!isset($$varname)) $$varname = '';
/**
* Sets the theme for ReCaptcha
79.160.59.72 15:04, 31 December 2011 (UTC)
Generally, it's better to set such variables after the inclusion of the extension in LocalSettings.php - I believe that's true for most extensions.
That's expected. You need to include the extension, then fill any required variables. Otherwise would open for explotation if register_globals was active.
I'm trying to use the QuestyCaptcha on a french wiki and i have small problems with accentuated caracters. I solved the first one enclosing questions in htmlentities() php function. But it doesn't seems to work for the answers. Ok, i could find others questions wich answers dont contain accents, but i like the ones ive already set up. Any advises appreciated. TulipVorlax 08:15, 21 December 2011 (UTC)
You shouldn't be using htmlentities in the question, as then your users would need to answer eg. école instead of école. What you need to do is to save the questions in UTF-8 (you were probably using windows-1252).
Are you meaning saving "LocalSettings.php" in UTF8 ? Because i dont know (yet) if Dreamweaver CS4 has a way of specifying encoding of PHP files, but maybe doing an edit with Notepad2 could help. TulipVorlax 22:48, 21 December 2011 (UTC)
Ok ! After a bit of thinking i decided to look for a php function and found the right one : utf8_encode().
Using it on answers that contain accents make an anon able to type and submit it (able to edit).
Thanks for the help. TulipVorlax 00:06, 22 December 2011 (UTC)
It does seem to support it [1]
Note that you would want UTF-8 with no BOM.
Even in a previous version of Dreamweaver i had that option set to UTF8. I dont know why it didn't work in this perticular case, but using the PHP function solved it.
Then, i discovered another bug... (See above.) Edit: Ok, i'll be updating the extension because it say on this page it has been fixed (the help page bug).
If a user tried the login procedure many times, after a certain occasions he got the CAPTCHA. But I had wanted to disable the login captcha, so I set the "$wgCaptchaTriggers['badlogin'] = false;" variable in the Localsettings.php. After this the user still got the picture, until I set the undocumented $wgCaptchaBadLoginAttempts variable to let's say 3000.
On my own login system the MediaWiki Captcha image doesn't show up, so it took me a lot of time to figure out why I got banned while I was testing the system.
Ban was occurred in includes/specials/SpecialUserLogin.php:523 in this code:
// Give general extensions, such as a captcha, a chance to abort logins
$abort = self::ABORTED;
if( !wfRunHooks( 'AbortLogin', array( $u, $this->mPassword, &$abort, &$this->mAbortLoginErrorMsg ) ) ) {
return $abort;
}
Somehow the LoginForm::ABORTED status changed to WRONG_PASS, so it made debugging extremely difficult.
Should I file a bug report about this, or is it enough here, in the talk section?
The problem of '$wgCaptchaTriggers['badlogin'] = false' not working should be fixed as of r107007. It wouldn't appear for new password failures, but as that user already had a "bad count", it was being shown anyway (which is now fixed).
Somehow the LoginForm::ABORTED status changed to WRONG_PASS, so it made debugging extremely difficult
This seems done in purpose, since the beggining (r27419): "Emulate a bad-password return to confuse the shit out of attackers"
When I try open Specail:Captcha/help I get following error:
Notice: Undefined property: QuestyCaptcha::$storage in /srv/http/wiki/extensions/ConfirmEdit/QuestyCaptcha.class.php on line 68 Fatal error: Call to a member function cookiesNeeded() on a non-object in /srv/http/wiki/extensions/ConfirmEdit/QuestyCaptcha.class.php on line 68
I had the same problem using 1.16. The following one-line change to QuestyCaptch.class.php seems to fix the problem:
===================================================================
--- QuestyCaptcha.class.php (revision 103604)
+++ QuestyCaptcha.class.php (working copy)
@@ -65,7 +65,7 @@
global $wgOut;
$wgOut->setPageTitle( wfMsg( 'captchahelp-title' ) );
$wgOut->addWikiText( wfMsg( 'questycaptchahelp-text' ) );
- if ( $this->storage->cookiesNeeded() ) {
+ if ( CaptchaStore::get()->cookiesNeeded() ) {
$wgOut->addWikiText( wfMsg( 'captchahelp-cookies-needed' ) );
}
}
Affirmative for MW 1.17. too. I have filed a bug report for this. Cheers
Neither myself nor my friends on instant messenger (worldwide) can use the download page to get this plugin. Very frustrating.
I'd like to make the messages that confirmEdit produces more obvious so that people understand what's going on. for example, right now after clicking "save page", the user is retured to the same page with the following at the top:
" Warning: You are not logged in. Your IP address will be recorded in this page's edit history. To edit this page, please solve the simple sum below and enter the answer in the box (more info): 94 + 10 = "
I'd like to style that message, ie put a red box around it, make it bigger, and make it clear the changes will not be saved until this action is completed. How can I make these changes? I notice the first half of the message is in a div with the css class of "mw-anon-edit-warning" - so I can style that, but the rest is fairly hard to get access to.
Thanks
The captcha input should use the new HTML5 attribute required="required". It's pretty safe cos non-supportive browsers ignore it. But it is much more user friendly (e.g. password inputs stay filled). QuestyCaptcha.class.php:
return "<p><label for=\"wpCaptchaWord\">{$captcha['question']}</label> " .
Xml::element( 'input', array(
'name' => 'wpCaptchaWord',
'id' => 'wpCaptchaWord',
'required' => 'required',
'tabindex' => 1 ) ) . // tab in before the edit textarea
"</p>\n" .
HTML 5 is half-baked and nothing more than a draft. I am against it. --Bachsau 19:26, 20 October 2011 (UTC)
What the heck? Read again. Non supportive browsers ignore unknown attributes. So you would prefer waiting 5-10 years while all major browsers support HTML5 alredy? LOL
We had to blacklist form submitting last year because WebKit was failing validation without telling you why. See bugzilla:23769.
Nonetheless, it seems interesting to add for the future. Added in r100422.
ReCaptcha and FancyCaptcha bouncing back after correct answer!? Ie. they are broken.
CASE CLOSED (see CASE CLOSED message below)
Hello, since MediaWiki appears to recommend this extension and this extension only for bot blocking, I hope someone will hop on this one real fast :)
Ever since I installed MW in this instance, I've had a problem with ReCaptcha where after correctly answering, or answering in general, the page would reload as if you had just hit submit, eg. for an edit, for another round of Captcha. I am pretty floored that I've never been able to find another account of this particular problem since it's basically a game breaker.
For a while I reverted to SimpleCaptcha since it works. But lately bots are becoming a nuisance so I gotta get some better defenses up before I go nuts. This morning I went thru the process of setting up FancyCaptcha (not so crazy about Google myself) but it bounces back just like ReCaptcha, suggesting the problem is in the ConfirmEdit end.
Until I get somewhere on this edits requiring Captcha will just not go thru. The wiki hasn't really caught fire just yet, so hopefully no one will be too bothered, but this is a problem nonetheless that needs to be documented on this page at the least.
Product Version MediaWiki 1.16.2 PHP 5.2.11 (apache2handler) MySQL 5.0.77 Installed extensions
Parser hooks ArrayExtension (Version 1.3.4 alpha) Store and compute named arrays Li Ding, Jie Bao and Daniel Werner ParserFunctions (Version 1.3.0) Enhance parser with logical functions Tim Starling, Robert Rohde, Ross McClure and Juraj Simlovic Subpage Fun (Version 0.3.1) Defines some new parser functions to get advanced informations about subpages. Daniel Werner Other ConfirmEdit (Version 1.0) (r82832) Provides CAPTCHA techniques to protect against spam and password-guessing Brion Vibber and ...
Maybe you should try upgrading to 1.17.x. and try again. ConfirmEdit seems to use some functionalities only available in recent versions. --Bachsau 14:30, 16 October 2011 (UTC)
For the record, 1.16.2 was the stable version of MediaWiki recommended on the website when I installed the ConfirmEdit extension.
Running ConfirmEdit on 1.16 since some early alpha in 2009 without problems. Maybe switch to simple math (at least to have a proper process). Also bot-looking accounts can be human too (that's what I experienced in the past months) so captchas like simple math are not working 100% well.
I stopped them by using $wgCaptchaQuestions using fairly simple insider questions that only my target group can answer. That stopped all spammers from registering and editing. --Subfader 18:49, 16 October 2011 (UTC)
I did say Simple Math does work (in the opening edit) but the two Captcha based options do not. I am familiar with administrating user generated websites. Simple Math isn't cutting it anyway, so I have to up the ante. Simple Math in a MediaWiki website could be conquered by the most rudimentary of scripts. I could code one myself in a half hour.
@Subfader: Please try one of the Captcha options if you can / see if they work for your 1.16 setup or not. Thanks.
Do the maintainers watch this page? I can't imagine there being a more important extension in the MediaWiki stable than this one.
@Bachsau: An upgrade on a lark is something I am not yet quite up to. Plus it seems like a backport would be in order.
OK, so turns out after pouring over the code FancyCaptcha was really fine. I just included an escaped character (single quote) inside the double quoted key and did not realize PHP treats an escape slash as a literal slash when the following character does not technically require escaping. C++ would have produced a single quote. But PHP produced \'.
Still ReCaptcha seems to be broken for some reason, but it's probably safe to not point fingers at ConfirmEdit, since it is an extension of ConfirmEdit. I'm not sure, but it seems like these captchas could be setup to fail more gracefully. For instance an error is indistinguishable from a wrong answer. The form could at least say the last answer was wrong to distinguish between that and a technical mishap.
CASE CLOSED.
The instructions said that ConfirmEdit includes ASIRRA, but I downloaded the version for 1.16.x and ASIRRA was not included. Downloaded ASIRRA and installed it and everything worked fine. I'm using the extension to prevent bots from registering (only confirmed users can edit my wiki, but the bots were still annoying) and I think this will work great!
As the documentation notes, you need to download the latest version of ConfirmEdit for Asirra to be included. (Or, conversely, you can do what you did, and download the separate Asirra extension.)
As Brted notes, Asirra is not in the latest version (trunc or named).
This extension doesn't seem to work completely with MediaWiki 1.17. I have turned it on for everything and it only seems to appear when registering a new account. --FlyingRagnar 04:30, 23 September 2011 (UTC)
Could support be added for PeopleSign? It's an interesting option. —
It could be added (or rather, reimplemented). Although it doesn't seem as hard to automate as peoplesign states.
I have ConfirmEdit setup with http://icl.cs.utk.edu/projects/papi/repository/index.php/Main_Page I see two different pages when I try to use ConfirmEdit One with Firefox 5.0.1 and another with Safari 5.1. I am using a mac. These are the screenshots
Firefox 5.0.1 http://icl.cs.utk.edu/projects/papi/repository/index.php/File:Firefox_5.0.1.png
Safari 5.1 http://icl.cs.utk.edu/projects/papi/repository/index.php/File:Safari_5.1.png
You're logged into the wiki on Firefox and you're logged out on Safari.
