Last modified: 2014-11-17 10:36:45 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 16717 - Write and implement new regex-based blacklist extension
Write and implement new regex-based blacklist extension
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
Extensions requests (Other open bugs)
unspecified
All All
: Low minor with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
https://www.mediawiki.org/wiki/Reques...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-19 23:18 UTC by MZMcBride
Modified: 2014-11-17 10:36 UTC (History)
7 users (show)

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


Attachments

Description MZMcBride 2008-12-19 23:18:39 UTC
Notes available here: http://www.mediawiki.org/wiki/Regex-based_blacklist
Comment 1 Mike.lifeguard 2008-12-20 00:12:20 UTC
Probably most of the spam blacklist bugs can be marked as depending on this, but someone more technically-minded might want to make those assessments.
Comment 2 Mike.lifeguard 2010-04-26 02:25:25 UTC
(In reply to comment #0)
> Notes available here: http://www.mediawiki.org/wiki/Regex-based_blacklist

Why is this not best implemented in AbuseFilter?
Comment 3 MZMcBride 2010-04-26 02:53:32 UTC
(In reply to comment #2)
> Why is this not best implemented in AbuseFilter?

<werdna> abuse filter is a crappy hack in general :)
Comment 4 MZMcBride 2012-09-05 20:42:40 UTC
This may be covered by <https://www.mediawiki.org/wiki/Admin_tools_development>. Copying a few relevant folks.

(In reply to comment #0)
> Notes available here: http://www.mediawiki.org/wiki/Regex-based_blacklist

Now moved to <https://www.mediawiki.org/wiki/Requests_for_comment/Regex-based_blacklist>.
Comment 5 Chris Steipp 2012-09-05 23:48:02 UTC
(In reply to comment #4)
> <https://www.mediawiki.org/wiki/Requests_for_comment/Regex-based_blacklist>.

Thanks for compiling the list MZ. Almost all of those features are available in AbuseFilter, so when the rfc is finished, it would probably be worth it to compare what it would take to add features to AbuseFilter vs write a new extension from scratch.
Comment 6 MZMcBride 2012-09-06 01:16:23 UTC
(In reply to comment #5)
> Thanks for compiling the list MZ. Almost all of those features are available in
> AbuseFilter, so when the rfc is finished, it would probably be worth it to
> compare what it would take to add features to AbuseFilter vs write a new
> extension from scratch.

AbuseFilter seems to serve a fundamentally different purpose than what's proposed here.
Comment 7 Jack Phoenix 2012-09-06 14:58:55 UTC
It seems to me that you are asking for [[mw:Extension:Phalanx]] to be created here. :)

Most of the requested features are indeed present in Phalanx, such as exact or regex matching, possibility to block edit/page move summaries, etc.

Though the following would be nice to have in Phalanx:
*Needs to validate to ensure proper regexes are input
-Marooned added a "QuickFix™ for bad regexes" over two years ago (see http://trac.wikia-code.com/changeset/23718), along with a to-do comment: "TODO: validate regexes on save/edit". This to-do is still valid and it's something that needs to be built.
*Needs to have safety check to ensure we don't ban all normal spaces or the letter K or whatever from page titles
-Phalanx assumes that the operator (human blocking stuff via it) knows what they're doing. If they don't...too bad. Given that we can't guarantee that all WMF stewards are and will be 1337 regex ninjas, this would be very nice to have, or otherwise Phalanx can render all WMF wikis unusable very easily.
*Needs Unicode normalization
-Not sure if this is already present
*Needs friendly output mode for non-Wikimedia Foundation wikis using the list
-Part of Phalanx's magic is that not everyone can view it (which is also true for private AbuseFilters on [name your favorite WMF wiki])...but I did once build a proof-of-concept API module for Phalanx, which would allow external wikis to use a certain Phalanx "list" (such as the WMF's in this case) as the master list. I.e. user X makes edit on external wiki Y, text is ran through WMF's Phalanx filters and if it matches a blocked phrase or whatnot on WMF Phalanx, edit is blocked. My proof-of-concept API idea had token-based authorization (so that you can't just set up a MediaWiki instance and effectively reverse-engineer the Phalanx blacklist), but that may or may not be a feasible idea. Just noting it down, though I know it sounds horribly proprietary and evil, but alas, not all anti-spam measures can be 100% open.
*Needs to warn sysops, but be overrideable upon confirmation
-Phalanx currently has the 'phalanxexempt' user right; Phalanx and its hook points are simply not initialized for users who have this right. It's not the same thing as seeing a warning message stating something like "www.example.com is currently Phalanxed, but since you are an admin, you can submit this edit by clicking here" or somesuch.
Comment 8 Andre Klapper 2012-11-09 21:07:39 UTC
MZMcBride: So should this report be closed in favor of Phalanx, and missing features turned into feature requests?
Comment 9 MZMcBride 2012-11-09 21:31:29 UTC
(In reply to comment #8)
> MZMcBride: So should this report be closed in favor of Phalanx, and missing
> features turned into feature requests?

Probably.

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


Navigation
Links