Extension talk:ConfirmEdit

Jump to: navigation, search

About this discussion

By clicking "Add topic", you agree to our Terms of Use and agree to irrevocably release your text under the CC BY-SA 3.0 License and GFDL
Jaideraf (talkcontribs)

I am getting the folowing error, what should I have to do?

Fatal error: Uncaught exception 'Exception' with message '.../w/extensions/ConfirmEdit/extension.json does not exist!
Florianschmidtwelzow (talkcontribs)

Fixed in documentation, ConfirmEdit itself doesn't have extension registration yet, so please use the "old" installation routine:

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

Sorry for the confusion!

Jaideraf (talkcontribs)

Thanks for answering, but now I am getting the following error message

Invalid or virtual namespace -1 given.

when editing with SemanticForms (without ConfirmEdit, SemanticForms works just fine)

Reply to "MediaWiki 1.25.1"

Solution for typical problems with reCaptcha and MediaWiki 1.25

Summary by Florianschmidtwelzow (talkcontribs)

If you're updating, start with deleting whole extensions/ConfirmEdit dir and copy it from mediawiki 1.25 archive. Replacing files won't do any good.

    • Error: PHP Warning: call_user_func() expects parameter 1 to be a valid callback, class 'ConfirmEditHooks' not found in /var/www/te_pl_wiki/includes/registration/ExtensionRegistry.php on line 169
    • Solution: include ConfirmEdit.php in your LocalConfig before loading a ReCaptcha.
    • Example:
require_once "$IP/extensions/ConfirmEdit/ConfirmEdit.php";
require_once "$IP/extensions/ConfirmEdit/ReCaptcha.php";
$wgCaptchaClass = 'ReCaptcha';
$wgReCaptchaPublicKey = 'your-public-key';
$wgReCaptchaPrivateKey = 'your-private-key';
    • Error: PHP Warning: call_user_func() expects parameter 1 to be a valid callback, function 'efReCaptcha' not found or invalid function name in /var/www/bw_fr_wiki/includes/Setup.php on line 678
    • Solution: edit extensions/ConfirmEdit/ReCaptcha/extension.json and remove "efReCaptcha" from "ExtensioFunctions"
    • Example:
"ExtensionFunctions": [
    • Error: PHP Warning: require_once(ReCaptcha/recaptchalib.php): failed to open stream: No such file or directory in /var/www/br_pl_wiki/extensions/ConfirmEdit/includes/ConfirmEditHooks.php on line 147
    • Solution: edit extensions/ConfirmEdit/includes/ConfirmEditHooks.php and edit function onReCaptchaSetup(), so it can find the file.
    • Example:
       public static function onReCaptchaSetup() {
               //error_log("cwd: ".getcwd()); // to debug currect dir location in log
               require_once( "extensions/ConfirmEdit/ReCaptcha/recaptchalib.php" );
Florianschmidtwelzow (talkcontribs)

> Error: PHP Warning: call_user_func() expects parameter 1 to be a valid callback, class 'ConfirmEditHooks' not found in /var/www/te_pl_wiki/includes/registration/ExtensionRegistry.php on line 169

You shouldn't use "only" ReCaptcha, it's a bad practice including the framework in a module, that's why it's not working with ExtensionRegistration. A much smaller solution, btw, would be to use: wfLoadExtensions( array( 'ConfirmEdit', 'ConfirmEdit/ReCaptcha' ) );

> Error: PHP Warning: call_user_func() expects parameter 1 to be a valid callback, function 'efReCaptcha' not found or invalid function name in /var/www/bw_fr_wiki/includes/Setup.php on line 678

Tracked in: phabricator:T100504

> Error: PHP Warning: require_once(ReCaptcha/recaptchalib.php): failed to open stream: No such file or directory in /var/www/br_pl_wiki/extensions/ConfirmEdit/includes/ConfirmEditHooks.php on line 147

Tracked in: phabricator:T100505

Reply to "Solution for typical problems with reCaptcha and MediaWiki 1.25"

Usernames still store even after a failed Captcha

2601:8:A780:899:3926:3B75:CDB8:25C8 (talkcontribs)

I've noticed that even when bots fail the Captcha it still stores the attempted username in my database. Does anyone know a way to change this so that the names only store if they pass the Captcha?

Nemo bis (talkcontribs)

Your observation is incorrect. If you fail the registration captcha, the account doesn't get created. Bots however keep trying until they pass the captcha: since most captchas are broken (including ReCAPTCHA) eventually they succeed.

Reply to "Usernames still store even after a failed Captcha"
Vedmaka (talkcontribs)

Is there any plans to support reCaptcha v2 ?

Kghbln (talkcontribs)

My impression is that this extension is only maintained in a way that it works for WMF purposes. The extensions page as well as gerrit "are full of unmerged patches, patch suggestions and so on". I guess the answer is no until someone takes over maintaining this extension.

Nemo bis (talkcontribs)

Well, people can help review: there is a patch by Florian, if everyone tested it and confirmed it works then folks like Emufarmers and others with +2 powers would presumably be more comfortable with merging.

Florianschmidtwelzow (talkcontribs)

+1 Nemo! The changes are open for all interested people for testing and giving feedback. That would help us a lot. There is a bug tracking the work on getting the new captcha into ConfirmEdit since a long time: phabricator:T84918 and there are two patches in ConfirmEdit (both linked in the task), so feel free to take one, test it and report back what happened :)

Kghbln (talkcontribs)

Thanks a ton Florian for making this happen! Lots of kudos form me!

Florianschmidtwelzow (talkcontribs)

A lot of kudos directly goes to @Krinkle: for reviewing and merging :) Thanks!

Reply to "reCaptcha 2.0"

Create account is no longer working on my wiki

Mojorhino (talkcontribs)

Initially, ConfirmEdit worked great, however recently I have had several people who were unable to create new accounts. I tried it myself on multiple computers with multiple different browsers & I am unable to create a new account.

  • My wiki Create account page is located here Vendopedia.com
  • Once you enter a username & password & select the Create your account button the intended page never loads

Any help resolving this would be greatly appreciated

Mojorhino (talkcontribs)

I figured it out

  • After looking up what Asirra was I was able to get it working again by commenting out the following
##require_once "$IP/extensions/ConfirmEdit/Asirra.php"; 
from my LocalSettings.php file

After saving the settings everything is working once again

Nemo bis (talkcontribs)

Indeed, that's because Asirra was discontinued by Microsoft.

Reply to "Create account is no longer working on my wiki"
Alex Liebrecht (talkcontribs)

Can you work with Captcha in Extension Blog Page? I would like to use Captcha in the comments of WikiBlog and still do not know how I can do this.

Can someone help me? Thank you in advance!

Reply to "Captcha for BlogPage Extension"

[Proposal] Creating questions for spambots but not for humans

Meshr (talkcontribs)

A lot of spamming accounts were creating in my wiki although I had recaptcha in ConfirmEdit extension. I did some investigation why it happened. Here is what I found:

  1. Actually SimpleAntiSpam feature works very efficiently (it is core mediawiki feature now). It stops a lot of spambots. It makes me to add it with some improvements to ConfirmEdit/QuestyCaptcha to make it to work also during account creation.
  2. No one spambot that I see had javascript support. Although some of them can break recaptcha.

My idea is to get rid of human captchas and to create invisible “captchas” for spambots instead. It works similar to QuestyCaptcha but instead of questions for humans some html/javascript code is injected. It does some work for detecting spambot and the result is sent back for verification instead of QuestyCaptcha answer. As an example for html/javascript code I made a random math function generator. Javascript is needed on spambot side to get the correct result for this function. Html/javascript code can be improved in future for detecting more complex spambots with javascript support. I pasted my ConfirmEdit/QuestyCaptcha patch here http://pastebin.com/4gVXR3GA It allows to have blank $wgCaptchaQuestions and to define optional $wgHTMLCaptchaQuestion function for more complex spambots. The main advantage is that you can stop spambots without defining any $wgCaptchaQuestions. Let me know if a spambot on your wiki can beat my simple javascript check.

Nemo bis (talkcontribs)

Such tricks work at small scale, not big scale. You can submit your patch against Extension:SimpleAntiSpam.

As for the questions, that's what the new ReCaptcha does. There is a patch in ConfirmEdit.

Meshr (talkcontribs)

My patch is against ConfirmEdit and QuestyCaptcha Extensions. It enables additional functionality in these Extensions that allows to write your own “new ReCaptcha” code. It stopped spam completely for me without any captchas/questions which I had before. The question is whether ConfirmEdit and QuestyCaptcha authors agree with these modifications.

Reply to "[Proposal] Creating questions for spambots but not for humans"

[Proposal] Use the same question on repeated requests

Benjaminpick (talkcontribs)

I am using ConfirmEdit with QuestyCaptcha to prevent spam account creation. However it was quite painful to watch a new user trying to register to my site, because he had to re-fill the form several times (password did not match, username already exists, forgot to re-type password) and each time he had to think about the answer of a different question.

To improve usability, I would suggest:

a) saving the selected question in the users' session and providing a link to "show a different question", b) or showing a different question only if it has been answered incorrectly. c) Yet a different approach would be to save the information "this is a human" into the session so that he only ever has to solve 1 captcha, even if the form reloads because of a different error.

For backwards compability, such behavior should be enabled via a config variable.

What do you think? I am willing to write a patch but am currently not sure which is the best approach.

Nemo bis (talkcontribs)

The approach followed in latest releases is to avoid reloading the form and the captcha at all if possible. Invalid username is now warned in-place, without submitting the form; something similar can be done for password mismatch; and there was agreement on wikitech-l that the password could be "remembered" upon form reload if the registration fails for other reasons.

Reply to "[Proposal] Use the same question on repeated requests"
Subfader (talkcontribs)

What if the user has $wgEnableWriteAPI = true? Will spam account creation be possible?

See also Thread:Project:Support_desk/API:_Disable_selected_dangerous_write_actions

MarkAHershberger (talkcontribs)

ConfirmEdit and other CAPTCHA implementations work with the API so if you depend on it for spam protection, it should continue to be protected.

You may also consider disabling account creation by

$wgAPIModules['createaccount'] = 'ApiDisabled';
Reply to "Risk with $wgEnableWriteAPI?" (talkcontribs)

Will Google's new No CAPTCHA reCAPTCHA API be supported?

Nemo bis (talkcontribs)

Probably yes, when someone writes a patch. :)

MisterLambda (talkcontribs)

I've just written one. Gotta just send it in now.

Kghbln (talkcontribs)

Great, since this seems to be a nice CAPTCHA solution.

MisterLambda (talkcontribs)

Wait for this patch to be applied. If you must have it, apply it now, though it's in review for a reason.

Kghbln (talkcontribs)

Cool, I just pinged someone who has a good insight into who may possibly deal with your commit, i.e. to work with you on improving it if there is the need to or to merge it for you into the repo. Excited to try it ... :)

Vedmaka (talkcontribs)

You can look at lightweight release for new reCaptcha - Extension:ReCaptcha. Only edit & account create protection. (talkcontribs)

Any new info when the no captcha will be ready for official ConfirmEdit release?