Extension talk:ConfirmEdit
 Archives |
- [History↑]
Contents
 First page |
 Previous page |
 Next page |
 Last page |
Hi,
I have the below configuration of my ConfirmEdit.php. My ConfirmEdit version is from Mediwiki 1.20.
$wgGroupPermissions['*' ]['skipcaptcha'] = false; $wgGroupPermissions['user' ]['skipcaptcha'] = false; $wgGroupPermissions['autoconfirmed']['skipcaptcha'] = false; $wgGroupPermissions['bot' ]['skipcaptcha'] = false; // registered bots $wgGroupPermissions['sysop' ]['skipcaptcha'] = false; $wgAvailableRights[] = 'skipcaptcha'; $wgCaptchaTriggers['badlogin'] = true; // Special:Userlogin after failure $wgCaptchaStorageClass = 'CaptchaSessionStore'; $wgCaptchaSessionExpiration = 30 * 60; $wgCaptchaBadLoginExpiration = 5 * 60; $wgCaptchaBadLoginAttempts = 3;
I also added this line to LocalSettings.php:
require_once( "$IP/extensions/ConfirmEdit/ConfirmEdit.php" );
When I tried to logging in 3 times with wrong password, there is no SimpleCaptcha displaying. But when I change it the wgCaptchaBadLoginAttempts to 1, it works perfectly.
I would appreciate if anyone could share their knowledged and experience if do I have missing in the configuration or is it just a bug of ConfirmEdit extension?
Thanks. James
My wiki has been overrun by spambots. Thankfully because of this extension, these spambots are not able to edit the pages, but they are still able to create an account - about 50 new accounts everyday.
How can I change the CAPTCHA settings to stop these spambots? I use the question CAPTCHA - it is the easiest to use and install and I want to keep it without adding new CAPTCHAs.
Is there another extension I can add which will limit the spambots creating a new account?
These bots only create new user pages - can I block all users from adding external links - but only to user pages?
Thank you.
Update:
Extension:AbuseFilter can handle much of anti-spam. I would think it's possible to restrict account creation using CAPTCHA (but I'm not too aware of such a method).
thank you so much jasper!
your a good person and good soul. I really appreciate you selflessly helping me.
Its so hard to get help sometimes! I am so thankful for you.
God bless you.
Hallo The following cod doesn't seem to work.
if(mt_rand(1,3)==1){ require_once( "$IP/extensions/ConfirmEdit/QuestyCaptcha.php"); $wgCaptchaClass = 'QuestyCaptcha'; $wgCaptchaQuestions[] = array( 'question' => 'Bitte schreibe, welches Tier das ist (erster Buchstabe groß):<img src="URL replaced!" style="width: 5%;"><a href="http://pastebin.com/8MESqzqh">Infos über das Bild</a>', 'answer' => "Answer replaced!" ); $wgCaptchaQuestions[] = array( 'question' => 'Bitte schreibe, welches Tier das ist (erster Buchstabe groß):<img src="URL replaced!" style="width: 5%;"><a href="http://pastebin.com/8MESqzqh">Infos über das Bild</a>', 'answer' => "Answer replaced!" ); }else{ require_once("$IP/extensions/ConfirmEdit/Asirra.php"); $wgCaptchaClass = 'Asirra'; }
It shows what it should show, but you aren't able to pass the test. When you click submit, you have to pass another of the possible antispam things. Please fix the bug.
Hi, I am not very good at PHP but I did what is explained to install confirmEdit, for example adding:
require_once( "$IP/extensions/ConfirmEdit/ConfirmEdit.php" ); require_once("$IP/extensions/ConfirmEdit/Asirra.php"); $wgCaptchaClass = 'Asirra';
into mediawiki/LocalSettings.php
I get no php error when I edit a page, but I don't see anything, nothing is asked to confirm Editing...
I tried to add
echo "HELLO!!!!";
at the end of ConfirmEdit.php and it is executed, I can see it when I did a page.
I tried mediaWiki 1.20 and the corresponding confirmEdit, then I tried mediaWiki 1.19 and the corresponding confirmEdit. Each time, I tried every $wgCaptchaClass possible, and it never worked. So what is the problem my friends ? My mediawiki works perfectly, I don't have any cache activated or even installed on my xampp. This is my config : ApacheFriends XAMPP Portable 1.8.1 + Apache 2.4.3
+ MySQL 5.5.27 (Community Server)
+ PHP 5.4.7 (VC9 X86 32bit thread safe) + PEAR
+ Strawberry Perl 5.16.1.1 Portable
+ Tomcat 7.0.30
+ phpMyAdmin 3.5.2.2
+ OpenSSL 1.0.1c
+ ADOdb 5.17
+ XAMPP Control Panel Version 3.1.0 by hackattack142 (Great Thanks!!))
See: http://www.apachefriends.org/f/viewtopic.php?f=16&t=46743
+ XAMPP Security
+ XAMPP mailToDisk 1.0 (write emails via PHP on local disk in <xampp>\mailoutput. Activated in the php.ini as mail default.)
Windows Vista Google Chrome 24
I you have an idea, could you please notice me at acx01b@yahoo.fr, Thank you very much !
And how about configuring the triggering? Did you do that? See Extension:ConfirmEdit#Configuration. Note that under the default configuration you have to do test edits with a normal user account, not your sysop user account, to see a captcha. You should also see a captcha when you go to register a new account though.
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
I suggest to add div tag with uniq ID which users can customize with own css.
To make it more obvious: why not just put the CAPTCHA just above the save button for anonymous users, so it looks like it's a part of the process?
I'm guessing this should work for most installs that merely whitelist/blacklist IPs (which is known in advance) and whitelists certain classes of users (again, known in advance). I think only the most advanced users are using REGEXs to allow certain edits to pass without CAPTCHAing.
No it's quite common to configure it to only trigger when adding external links (so the edit needs to be submitted before deciding whether or not to show a captcha)
But yes for people setting it to trigger on *all* edits, it would indeed make sense for the captcha to be displayed alongside the 'save' button. I suppose if it was really clever, it would re-arrange the way the form works in accordance with how triggering is configured.
Hello,
the Recaptcha module is not working in the mobile version for me. The problem is that the Javascript is filtered or removed by the mobile version.
According to this discussion, an extension has to register specifically for the mobile version. http://www.mediawiki.org/wiki/Extension_talk:MobileFrontend#Is_JavaScript_filtered.3F_25404
Any ideas?
Thank you, Christoph
When using QuestyCaptcha the form appears when the user has done changes and is on the same page (edit). The user is not aware that a captcha must be filled. Moving the Captcha to the bottom of the page or highlight it by css would change the problem.
That includes the version of the extension that is bundled with 1.20.
If you set $wgCaptchaClass = 'FancyCaptcha' in your LocalSettings.php you will get an HTTP 500 error if you attempt any operation involving a captcha such as creating a new account. If you look in FancyCapthca.class.php you will see it includes a call to getWikiId. The FSFileBackend class does not have that method in 1.20, although the trunk version does. The Apache error_log confirms that the failure is due to an attempt by FancyCaptcha.class.php to call FSFileBackend::getWikiId.
I am currently using the 1.19 version of this extension with 1.20 without any problems.
I can't seem to find a working version. I have tried downloading the latest version and 1.19 in the ConfirmEdit page and it does not work with mediaiki 1.20. Any captcha option gives me a 500 error.
FancyCaptcha does not work for me in MediaWiki 1.20.3. It says on text submit
Internal error [41207728] 2013-03-16 07:01:45: Fatal exception of type MWException
Very sad... Can somebody fix it. I muss FancyCaptcha, and not a php developer :-(((
Probably the same bug as bugzilla:46132, can you comment there please?
I do not know...
If you can tell me how to see MediaWiki or php Error log or something like this, I can tell you more about this error. For now only one thing I have is that message it browser. Since MediaWiki and other php scripts does not use common web server error log to report errors, I really do not know how to debug it...
I found the source of the problem: the source was me.
For some unknown reason in previous installation I've configured FancyCaptcha right in the extensions/ConfirmEdit/FancyCaptcha.php file and while upgrading I've replaced all my custom configuration with a default one. So nothing worked.
So there is no bug in FancyCaptcha in my case (what about Prh47bridge's case I do not know), but there is a wish requests
1. to add some more diagnostics in cases when capcha files are missing or wrong
2. May be do some sanity check on initialization, i.e. check that capcha dis exists or something, so when you run media wiki on wrong configuration you will get warning even when you are not editing anything. May be add this check to upgrade script if it is possible...
I found the message given on the login screen, at ConfirmEdit.i18n.php and edited it to mention the Asirra cat puzzle that I'm using (by default it talks about a simple math problem). Now how do I edit Special:Captcha/help ? Even using the full address and adding on &action=edit wouldn't let me edit that page.
Okay, so I have this code in LocalSettings.php
require_once("$IP/extensions/ConfirmEdit/ConfirmEdit.php"); require_once("$IP/extensions/ConfirmEdit/QuestyCaptcha.php"); $wgCaptchaQuestions[] = array( 'question' => 'What does <i>Pyroraptor</i> mean?', 'answer' => 'Fire thief' ); $wgCaptchaClass = 'QuestyCaptcha';
However, when I try to log in, this shows up:
Fatal error: Class 'QuestyCaptcha' not found in /home/u686002980/public_html/raptor/wiki/extensions/ConfirmEdit/ConfirmEditHooks.php on line 16
What do I do?
Two days ago I visited 500 wikis. I chose to register on about 40 of them I was interested in, and 20 out of 40 had registration closed because they had been unable to stop spam (one required authorisation of new accounts and another used Extension:ConfirmAccount). As for the other 20, which managed to keep editing open, none was using FancyCaptcha, SimpleCaptcha or MathCaptcha; one or two used Asirra, something like three reCAPTCHA, two used what seemed QuestyCaptcha but with math questions in blurred images, and several were using QuestyCaptcha, with questions tightly adapted to their audience, not always obvious (and impossible for me in the case of SpongeBob questions in German). Edit: sorry, now that I think of it there was one wiki using what looked like FancyCaptcha, but they had such distorted images that it was very hard; I've not checked in their recent changes if this configuration was effective.
I'd like this scenario: All unregistered users get the CAPTCHA on edit, registered users only get it if they add a URL, and autoconfirmed users never get it.
This could be a popular setup, but unfortunately it's not possible with the current customization options. My recommendation for how to fix this is to have it work just like user rights:
$wgCaptchaTriggers['*']['edit'] = true; $wgCaptchaTriggers['user']['edit'] = false; $wgCaptchaTriggers['user']['addurl'] = true; $wgCaptchaTriggers['autoconfirmed']['addurl'] = false;
I think this makes a lot more sense than the binary skip/no-skip approach, and it would allow people to customize ConfirmEdit however they want. I've submitted a bug/enhancement for this as well.
Is it possible to bypass this extension in this manner:
- The extension allows for a correct solution to be presented then saves this as a cookie, os that people aren't inconvenienced when using multiple tabs/windows. Isn't it possible for someone to manually enter a solution, then just keep spamming the site, possibly (with a non-static IP connection) periodically putting in ipconfig /renew on the command line to get a different IP address? It seems like the cookie that stays on the computer would allow a person to basically completely bypass this after a single correct answer is given. I'd like to turn this cookie off, but I'm not sure whether that would break anything else. I only have this turned on for account creation, I turned this off for edits in my localSettings file.
I recently installed ConfirmEdit on Lylat Wiki and have been getting this error message when someone signs up.
Fatal error: Call to undefined method TitleBlacklist::singleton() in ...../w/extensions/TitleBlacklist/TitleBlacklist.hooks.php on line 85
For your information, here is my install information.
- MediaWiki 1.19.2
- PHP 5.3.16 (apache2handler)
- MySQL 5.1.65-cll
Is this a poor install, poor file... or bug I need to report.
I notice there aren't a lot of sites that use it. Have a lot of spammers cracked it yet?
Fancycaptcha is the captcha Wikimedia projects use now at least for some things, isn't it? AFAIK it's completely useless.
I figured as much. It didn't look very secure.
When I click the download link, it loads indefinitely. What went wrong?
We're currently in the process of switching to Git from Subversion. Just try again.
> We're currently in the process of switching to Git from Subversion. Just try again.
The process of switching to Git from Subversion takes indefinitely. I have the same trouble, cannot download ConfirmEdit for MediaWiki 1.19.x: http://www.mediawiki.org/wiki/Special:ExtensionDistributor/ConfirmEdit
== [edit]
Download MediaWiki extension Jump to: navigation, search Error from Extension Distributor remote client: Lock wait timeout.
== [edit]
I have followed the directions detailed in the installation and cannot get ConfirmEdit to ever require anything to be entered. There is no captcha showing up on my pages. I have tried each of the Captcha types and none work for my site. Visiting the Versions page confirms that it is installed but it will not work.
My LocalSettings.php looks like this after the setup:
# ConfirmEdit $wgGroupPermissions['*' ]['skipcaptcha'] = false; $wgGroupPermissions['user' ]['skipcaptcha'] = false; $wgGroupPermissions['autoconfirmed']['skipcaptcha'] = false; $wgGroupPermissions['bot' ]['skipcaptcha'] = false; // registered bots $wgGroupPermissions['sysop' ]['skipcaptcha'] = false; $wgCaptchaTriggers['edit'] = true; $wgCaptchaTriggers['create'] = true; $wgCaptchaTriggers['addurl'] = true; $wgCaptchaTriggers['createaccount'] = true; $wgCaptchaTriggers['badlogin'] = true; require_once("$IP/extensions/ConfirmEdit/ConfirmEdit.php"); require_once("$IP/extensions/Asirra/Asirra.php"); $wgCaptchaClass = 'Asirra';
This is at the bottom of my settings. I can't figure out whats stopping it from working.
- Using MediaWiki 1.19.2 - Using default 'vector' skin to test. - Using latest ConfirmEdit that came with the upgrade to 1.19.2 - Using separate Asirra as suggested by the install page.
My problem are spam links in the user namespace. I just spent quite a long time to find my configuration mistake, and in the end I realized that in the main NS my settings are working correctly (trigger on addurl), but not in the user NS. Even specifying $wgCaptchaTriggersOnNamespace[NS_USER]['addurl'] = true; doesn't show any effects... Why is this??? (And if intended, couldn't it be added ot the documentation in some obvious place...?
Edit: Actually, when the settings for user NS seem to be inversed from what I expect: $wgCaptchaTriggers['create'] = false; $wgCaptchaTriggers['addurl'] = true;
The captcha is displayed when I add a page with/without URL, while it is missing when I add a URL to an existing page.
When I try "Log in / create account" displays a blank page.
MediaWiki 1.18 ConfirmEdit 1.19 Wiki http://trazoide.com/wiki
Thank you.
I don't see any blank page at your link or when clicking "Log in / create account".
Yes, you're right. I took off for the wiki ConfirmEdit to continue to operate. Now I restart it. Thanks for your interest.
Ello. Asirra seems borked in my installation. Even when solved correctly and the password is correct, it reports this to the user upon logging in:
Login error
Incorrect password entered. Please try again.
It should be noted that it says this above it:
To help protect against automated password cracking, please solve the simple sum below and enter the answer in the box (more info):
ReCAPTCHA technically works fine, but it seems to not be secure enough.
Tried it on 1.18.0, now running 1.19.0b2 and still nothing.
Asirra seems to be broken with IE8 and IE9.
Login error Incorrect or missing confirmation code.
fails on multiple independent sites.
I am using the following version:
MediaWiki 1.19.1 ConfirmEdit Version 1.1 Firefox 13.0.1
reCaptcha is working fine. I can edit and save edits by solving reCaptcha. But, when switching to Asirra, the same additional line displays:
To help protect against automated password cracking, please solve the simple sum below and enter the answer in the box (more info):
Then, no matter if you select all the cats, it just doesn't allow you to pass. I think one more captcha is getting activated but with no input box.
Also, wgAsirraEnlargedPosition, wgAsirraCellsPerRow, etc. set in Localsettings.php is not getting respected/read.
Note, Asirra was working fine with 1.18. Upgrade broke it.
Found the cause: client-side value Asirra_Ticket is supposed to contain the ticket for the CAPTCHA, but this is blank when it is passed to the server.
Did you have a fix? Should this extension be downgraded or noted that Asirra doesn't fully work?
I'm waiting on this one too, I opened a wiki which got spammed to hell so looking for something robust like this before I launch my next one. I get the sum question and the cats. Using 1.19
I have it working but only since I have set editing rights only to registered users. Works fine when registering as a user but I do want my wiki to be open to non user editing and was hoping I could use Asirra to stop spammers and enable anyone to edit.
I still get the sum question with no where to answer it alongside the cat pictures if I use this to check non registered users
Hopefully folks read this discussion before enabling this mode. I made a note on the main page warning folks of reported issues with IE and Asirra. It was rejected. Anyone expecting users to register with IE8/9 will find that they won't succeed, it's rather simple to check to see it fail, enabling this Asirra with this extention will block about 1/3 of your potential editor base. I'm not even sure where to file a bug for this extension, otherwise I would have already done so. If i new PHP a little better, perhaps I would offer up a fix.
First page |
Previous page |
Next page |
Last page |
