Last modified: 2014-02-25 23:01:13 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T20110, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 18110 - Allow AbuseFilter to force the user to solve a captcha
Allow AbuseFilter to force the user to solve a captcha
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
AbuseFilter (Other open bugs)
unspecified
All All
: Low enhancement with 5 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 26765 31989 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-23 02:35 UTC by Mike.lifeguard
Modified: 2014-02-25 23:01 UTC (History)
15 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Mike.lifeguard 2009-03-23 02:35:10 UTC
To either slow down human abusers or weed out bots, please allow AbuseFilter to present a CAPTCHA & allow the change only if solved. Yes, I'm aware that captchas are mean to humans both blind and sighted (though of course a particular horror from an accessibility standpoint) - they'd have to be used sparingly etc, but that's a useful option IMO.
Comment 1 MacGyverMagic 2009-03-28 13:48:44 UTC
This will only result in annoying good editors. We already have throttling and disallowing at our disposal for problematic edits. I don't see the additional benefit of a CAPTCHA. 
Comment 2 Mike.lifeguard 2009-04-13 21:04:02 UTC
This would be no different in essence than wgCaptchaRegexes (only better in practice)
Comment 3 Gurch 2009-04-13 22:12:51 UTC
(In reply to comment #2)
> This would be no different in essence than wgCaptchaRegexes (only better in
> practice)

Except that $wgCaptchaRegexes isn't open to tinkering by anyone with sysop status. :)
Comment 4 Mike.lifeguard 2009-06-29 23:54:23 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > This would be no different in essence than wgCaptchaRegexes (only better in
> > practice)
> 
> Except that $wgCaptchaRegexes isn't open to tinkering by anyone with sysop
> status. :)
> 

That's the point of this request.
Comment 5 Gurch 2009-06-30 18:40:24 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > This would be no different in essence than wgCaptchaRegexes (only better in
> > > practice)
> > 
> > Except that $wgCaptchaRegexes isn't open to tinkering by anyone with sysop
> > status. :)
> > 
> 
> That's the point of this request.

And it's why I don't agree with it. As MacGyverMagic already said, the this would annoy newcomers trying to make useful contributions far too much (rather like the abuse filter itself...)
Comment 6 Mike.lifeguard 2009-06-30 20:15:34 UTC
(In reply to comment #5)
> And it's why I don't agree with it.

Then don't enable it on whatever wiki you contribute to; the request is still valid.
Comment 7 Gurch 2009-07-02 17:06:00 UTC
(In reply to comment #6)
> Then don't enable it on whatever wiki you contribute to; the request is still
> valid.

Oddly enough, I don't have total control over what gets enabled where. If it were that simple, I wouldn't be posting here. :)

en.wikipedia has a history of conducting polls on technical features where 80% of the voters have no or little understanding of what it is they are voting for. Thus I consider feature requests that could damage the project best nipped in the bud.
Comment 8 Andrew Garrett 2009-07-16 17:04:29 UTC
(Batch change)

These are low-priority miniprojects that I can mop up at some point when I'm doing general code work as opposed to working on a specific projects.
Comment 9 MZMcBride 2011-01-17 09:47:05 UTC
*** Bug 26765 has been marked as a duplicate of this bug. ***
Comment 10 db [inactive,noenotif] 2011-10-28 15:41:38 UTC
*** Bug 31989 has been marked as a duplicate of this bug. ***
Comment 11 Beau 2011-11-15 20:46:11 UTC
It would be great to have beside configuration variable in LocalSettings.php ability to switch on/off this function for a specific filter.
Comment 12 Helder 2012-10-30 00:32:24 UTC
This would also serve as a workaround for bug 41522.
Comment 13 MZMcBride 2013-06-21 02:07:45 UTC
The variable should be named hate_blind_people or something. ;-)

(Even a surly variable name like this would still be better than most of the other AbuseFilter variable names, heh.)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links