Extension talk:ConfirmEdit

Jump to: navigation, search

About this board

Archives 
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

Why still using old hook for enabling extension?

2
209.239.103.227 (talkcontribs)

Why do the instructions on the extension page instruct users to use the old method to call this extension in LocalSettings.php?

Prior to 1.25: <nowiki>require_once "$IP/extensions/ConfirmEdit/ConfirmEdit.php";</nowiki>

Shouldn't the instructions advise users to use this standard method?

1.25 and newer: <nowiki>wfLoadExtension( 'ConfirmEdit' );</nowiki>

See the [Extension:Cite Cite] extension's installation instructions for an example.

Florianschmidtwelzow (talkcontribs)

The main part of ConfirmEdit doesn't support ExtensionRegistration yet, it's tracked in task T88047. As long as this isn't resolved, adding the new installation with the use of ExtensionRegistration wouldn't work :)

Reply to "Why still using old hook for enabling extension?"
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!

Missing captcha in WikiEditor & Unclickable in Visual Editor

1
71.67.124.174 (talkcontribs)

I just installed the extension, and tried the questycaptch as outline in the sample.

It works in visual editor 0.1.0, but i guess VE has a bug where we cannot click inside the input box. Does anyone has the same issue? Was there a fix on VE that i need to work on?

I tried WikiEditor. After i clicked publish, it does not show me the captcha at all. I have expanded the publish box but there was missing captcha.

What editor does everyone use here for the captcha to work best in?

AT

Reply to "Missing captcha in WikiEditor & Unclickable in Visual Editor"

Reverts on ConfirmEdit's QuestyCaptcha

6
Nemo bis (talkcontribs)

Hi

I noticed you reverted my edits to the ConfirmEdit Extension and, of course, I don't like it so I'm here to propose other changes.

The first edit removed a Previous Edit I made and added: DO NOT use an exact copy of the dynamic questions from the link -- they've been cracked by spammers. However other dynamic questions in the style of the questions presented are highly effective.(Blue used to high light removed section). Since the new posted questions have not been cracked by spammers it's no longer a true statement. How 'bout we change it to:Do Not use an exact copy of the dynamic questions from the link; it makes it easier for spammers to crack if everyone has the same questions. However other dynamic questions in the style of the questions presented are highly effective. Or something along those lines?

Your other revert was on this add:

QuestyCaptcha as an Alternative to the ConfirmAccount Extension

As an alternative to ConfirmAccount you can use the QuestyCaptcha, in following manner:

DO NOT disclose the answer in the question and ask a question that only you have the answer to. Redirect users to a page to that contains an email form to ask to join your wiki. This would require a contact page be somewhere inside your wiki. You can add an email page with this extension:ContactPage, via the Widgets Extension using the Widget:Google Form, or in several other ways.

Example Questy Confirm Account Alternative:

require_once "$IP/extensions/ConfirmEdit/QuestyCaptcha.php";
$wgCaptchaClass = 'QuestyCaptcha';
$arr = array (
'You can only join this wiki by entering the secret code below.To receive the secret code you must register via email on this page:<a href="ContactPage">Contact Page</a> ' => 'YourSecretonlytoldbyemail',
);
foreach ( $arr as $key => $value ) {
        $wgCaptchaQuestions[] = array( 'question' => $key, 'answer' => $value );
}

Or alternatively if this is a small wiki community, and you do not wish "outside" users, you could only tell the secret answer to your selective community.

Small Community Example:

require_once "$IP/extensions/ConfirmEdit/QuestyCaptcha.php";
$wgCaptchaClass = 'QuestyCaptcha';
$arr = array (
'This is a Members Only wiki. If you are a Member please enter the secret code below' => 'YourSecretcode',
);
foreach ( $arr as $key => $value ) {
        $wgCaptchaQuestions[] = array( 'question' => $key, 'answer' => $value );
}

Now I can understand that maybe that section should not be included in the page about setting up Captcha, but I still think it makes a more effective way of access control then Extension:ConfirmAccount. And since ConfirmEdit is part of the core the ways I listed above are easier for most then ConfirmAccount. What about adding it as a subpage to the extension with one line addition on the front page of the extension?

Something like this:

(sentence above ending).... highly effective.

(Add) Questy Captcha can also be used as an Alternative to the Confirm Account Extension. See: [[Subpage Name]]

Anyways just my thoughts. All the best to you.

This post was posted by Nemo bis, but signed as Christharp.

Nemo bis (talkcontribs)

Hello, I moved your question here so that others can give their opinion too. From your reply it seems you didn't read my edit summary: «Doesn't matter that they've been changed, they mustn't be copied anyway. QuestyCaptcha is part of ConfirmEdit, not an alternative to it. And we don't recommend usage of ConfirmEdit as a password restriction to editing.»

I still don't understand your usage of the word "alternative" and your usage of QuestyCaptcha for unguessable answers is not prevalent across MediaWikis.

Christharp (talkcontribs)

Hi

I did read your edit summary. Points:

  1. my suggested first new edit acknowledged your statement about them not being changed, but also acknowledged the truth that they no longer have been cracked.
  2. the second edit about using Questy as an alternative to ConfirmAccount -- is it can be used instead of the ConfirmAccount extension. The ConfirmAccount is a totally different extension for preventing account creation at will, allowing only sysops the power to confirm an account and add a user. Since, however, that requires downlaoding a new extension, adding a new database, etc., if the same functions can be achieved by other means, especially by using an extension that's part of the core it just makes sense. Basically ConfirmEdit makes the ConfirmAccount extension obsolete.

Sorry for my lack of clarity. All the best to you. I'll check out the talk page.

Nemo bis (talkcontribs)

Ok. But ConfirmEdit is an extension, although it's true that ConfirmAccount is not bundled. Installing ConfirmEdit and then using it just for password protection of account creation (you don't use the password captcha for anything else, right?) might be a bad idea for performance too, if its code is called on every edit.

More importantly, having to ask a password before registration is a bad user experience in general. At that point, why couldn't you create them an account directly when asked? Or use InviteSignup to offer them the possibility?

I do see a use for your idea; but I'd like to understand better why you consider it the best solution for your case. We need its rationale to be explained well in documentation, or we'll mislead users.

Christharp (talkcontribs)

Hi

The assumption that I think the ConfirmAccount is making is that wiki is set up to only allow editing from users (that assumption could be false). That assumption is the assumption I was assuming when I wrote the section -- forgetting some wikis allow editing by anonymous people.

The code would not be called anymore then it's currently called. It would be invoked when someone went to the sign in page to join, which is the same as it is when you Use ConfirmEdit now.

Bad User experience? Anymore then a Captcha? All Captchas are a bad user experience, but without them we would be flooded with spam bots. Recently on a wiki I own the Questy questions were cracked and I was flooded with something on the order of 1000 spam accounts before I stopped it. That wiki, unfortunately, is always open to the public so the answer I gave here doesn't work.Password or Captcha before registration suck, but both answer real world problems.

The problem with InviteSignup is the assumption that the wiki admin will know everyone who wishes to join. A previously unknown person could not join the wiki.

The section I wrote was for a detailed purpose (if not expressed clearly): showing how with ConfirmEdit Questy one could do what the ConfirmAccount does. If one can use a Core extension to get rid of the need of another extension, in this case ConfirmAccount, let's make life easier by showing everyone how. Yes, it's not the purpose that ConfirmEdit was designed for, but that just shows the flexibility of the code. My method takes someone a few minutes to set up, if that, while the alternative is loading another extension, creating tables, etc., which is just a waste of time.

Once again I suggest a very detailed subpage on the method & it's purpose (replacing another extension).

All the best. Hopefully I'm providing some clarity that my earlier writing didn't.

Nahiyan8 (talkcontribs)

I would support keeping the information. Here are my main points:

  1. A user of MediaWiki can do what they want or need, whether it's supported or not.
  2. MediaWiki can choose whether to support a method. (If it is sensible of course)
  3. It depends on a wiki's scope whether to add information, guidelines, etc. on such information.

On (1), a MediaWiki user could use it as described, to use QuestyCaptcha as an editting password. I can think of a use-case for this, such as when a wiki-admin decides it is too cumbersome to create accounts by-hand and can simply distribute the key to a group of people who is supposed to edit. Of course, as User:Christharp said, it can provide ease to the wiki-admin, as a they can do what they want, the task should be to make what is sensible, simple? It's a clever idea, one that a clever wiki-admin could figure out for themselves. Ideas such as these should be told to others who may need such a feature, but haven't thought of using it for the purpose of restricting access.

On (2), MediaWiki (and along with it, the Wikimedia Foundation) has their own incentives, and concepts such as free information, open access, the wiki way etc. However, a wiki may have many uses, perhaps it is a private wiki for company-information, or a "personal" wiki which does not concern the rest of the public and is limited to members of a group. It my opinion that some of these incentives should be encouraged but never mandatory for a MediaWiki user.

On (3), MediaWiki.org's sole task is to document the usage of MediaWiki and related software. As this is a clever use that uses the software, it depends on whether they support it (point (2)), or whether they should distribute this information.

Reply to "Reverts on ConfirmEdit's QuestyCaptcha"

The current version of this extension is not compatible with 1.20

9
Prh47bridge (talkcontribs)

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.

143.106.157.72 (talkcontribs)

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.

Nataraj (talkcontribs)

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 :-(((

Nemo bis (talkcontribs)

Probably the same bug as bugzilla:46132, can you comment there please?

Nataraj (talkcontribs)

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...

Nataraj (talkcontribs)

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...

Nataraj (talkcontribs)
93.41.94.161 (talkcontribs)

I'm getting the same issue:

  [74137648] 2014-11-06 01:04:27: Fatal exception of type MWException


When I set "$wgShowExceptionDetails = true;" in LocalSettings.php, it gets expanded to:

  [3fec957a] /index.php?title=Special:UserLogin&returnto=Main+Page&type=signup Exception from line 161 of   
  /example.com/htdocs/extensions/ConfirmEdit/FancyCaptcha.class.php: Ran out of captcha images

For previous people participating in this thread, a similar error turned out to be wrong location of the images. Here, it's not the case:

  $wgCaptchaDirectory = "/tmp/captcha";
  # ls /tmp/captcha/
  image_0c30eb32_909fdf4961658cbf.png  image_4b5777ea_02ea373d0eb70a08.png  image_7c662fed_bb479185e2e52234.png 
  (...)

Any ideas what can be wrong? This is with MediaWiki 1.23.6.

Lieutenant S. Reznov (talkcontribs)

I'm using the question setting and it seems cause a 500 error on the account creation page.

This post was posted by Lieutenant S. Reznov, but signed as Inquisitor Ehrenstein.

Reply to "The current version of this extension is not compatible with 1.20"
Mijunkin~mediawikiwiki (talkcontribs)

Is there an alternate download site? It looks like others have had issues as well. When I try to download for 1.18 it gives me "Error from remote subversion client: Lock wait timeout." over and over. Help? --Mijunkin (talk) 03:22, 30 April 2012 (UTC)

This post was posted by Mijunkin~mediawikiwiki, but signed as Mijunkin.

Jasper Deng (talkcontribs)

Basically, for some reason the repository is locked at the moment. I would suggest a manual download using your own Subversion client.

Reply to "Download error"

Fatal error when I try "Log in / create account"

12
Unikum~mediawikiwiki (talkcontribs)

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

This post was posted by Unikum~mediawikiwiki, but signed as Unikum.

Subfader (talkcontribs)

Try the latest version of ConfirmEdit

Unikum~mediawikiwiki (talkcontribs)

I use trunk version from SVN (last update at 2011-12-17).

This post was posted by Unikum~mediawikiwiki, but signed as Unikum.

JonathanWilliford (talkcontribs)

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.

Unikum~mediawikiwiki (talkcontribs)

Thanks for the tip.

This post was posted by Unikum~mediawikiwiki, but signed as Unikum.

Unikum~mediawikiwiki (talkcontribs)

Problem appears since r106097.

This post was posted by Unikum~mediawikiwiki, but signed as Unikum.

82.29.217.133 (talkcontribs)

For MW 1.16.5 with r107316 I have solved this problem by changing

$wgRequest->getIP() to wfGetIP()

82.29.217.133 (talkcontribs)

For MW 1.16.5 with r107316 I have solved this problem by changing

$wgRequest->getIP() to wfGetIP()

Platonides (talkcontribs)

You were using a very recent ConfirmEdit with an old MediaWiki.

Brted (talkcontribs)

I got this error when I installed 1.18.3 today. New MW, new ConfirmEdit. I fixed it by bringing over my old copy of captcha.php. That version uses wfGetIP() Brted (talk) 02:01, 29 April 2012 (UTC)

70.252.129.166 (talkcontribs)

In my case it was Asirra that was causing the problem. I manually downloaded the latest version of that and overwrote the files in the ConfirmEdit directory with it. All works fine now.

Reply to "Fatal error when I try "Log in / create account""

[QuestyCaptcha] Help page on 1.18 is broken

4
Unikum~mediawikiwiki (talkcontribs)

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

This post was posted by Unikum~mediawikiwiki, but signed as Unikum.

Geraschenko (talkcontribs)

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' ) );
     }
   }
Reply to "[QuestyCaptcha] Help page on 1.18 is broken"

Make ConfirmEdit "Messages" more abvious

5
199.85.228.100 (talkcontribs)

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

Subfader (talkcontribs)

Edit the according message in the MediaWiki NS. Find it on Special:Allmessages.

Unikum~mediawikiwiki (talkcontribs)

I suggest to add div tag with uniq ID which users can customize with own css.

This post was posted by Unikum~mediawikiwiki, but signed as Unikum.

198.84.187.124 (talkcontribs)

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.

Harry Wood (talkcontribs)

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.

Reply to "Make ConfirmEdit "Messages" more abvious"