AbuseFilter::getConsequencesForFilters uses filter ids as
array keys, that causes problems if both local and global
filters were hit, because array_merge reindexes arrays.
Example:
https://www.mediawiki.org/wiki/Special:AbuseLog/18687
Change-Id: I81cb110322461e30113199cfa313cd8e8e8b2262
It's observed that some vandals use {{subst:void}} to trick the system
and other users and this new variable may help.
It would be nice to be possible to diff this variable against
old_wikitext, but it needs some performance consideration.
Change-Id: I4c4c4e806663363b40936363d659c42016e18cf6
lot of code was using ::merge() to create a new AbuseFilterVariableHolder
this is now simplified using a single addHolders method.
merge() still exists as its usful as a static function.
addHolder() is deprecated.
Change-Id: Ia4f6a56f642242a04cf2973b74ce44d91fce00eb
AF is setting several lazy load variables for the currently editing user.
To do this it's passing along the user name extracted from a user object
and generating a new user object later from that name which is of course
pointless. With this patch I'll pass user objects directly to prevent that.
On top of that I've deprecated a method in AFComputedVariable::compute which
was redundant as there is a more generic one which can solve that task
just fine.
Furthermore I've changed the logging behaviour from serializing the whole
AbuseFilterVariableHolder object to only store the variables. That has two
major advantages:
* The amount of data that needs to be saved on a filter hit is reduced
to about 1/10 of what the old version needed.
* This is much more forward compatible as the old way of saving this
relied on the class structure to stay the same while this is a simple
array containing the vars.
On top of that we now only log variables already set by the time
a filter is hit. On top of the obvious performance increasement
that makes it easier for the user to spot the relevant data.
Another thing this change alters is the way the AbuseFilter internally
works with AbuseFilterVariableHolder objects. Right now we use one for
testing the filter(s) and later we use another one to compute the same
data again in case a filter was hit (for logging)!
This is not thoroughly tested yet, but way more sane than what we're
currently doing!
Change-Id: Ib15e7501bff32a54afe2d103ef5aedb950e58ef6
$wgAbuseFilterAnonBlockDuration didn't default to the actual
value of $wgAbuseFilterBlockDuration but to the default value
of that (which is indefinite). Fixed that (untested)
Change-Id: I26a929bfba997b80445a108e212030fe7faa6428
During testing the context does not always contain a valid
Title object. In those cases AbuseFilter will fail hard.
This changeset makes the filter survive some of those
failures.
Change-Id: I0b2247432619ddf15cc17ed41b4b7a6a11e910e0
This creates a $wgAbuseFilterAnonBlockDuration, which
allows for IP blocks to have a different length.
For backwards compatability this is default set to
$wgAbuseFilterBlockDuration.
Change-Id: Ibfd5c9639317150442f745a5759f3c34b38de274
Currently $wgAbuseFilterDisallowGlobalLocalBlocks checks against a
hardcoded list for "block actions", which means that extensions
like GlobalBlocking cannot add actions to it.
Change-Id: I6ac5125782cf0029447948d6d0080103700e397c
The title in the context provided for an edit may be a special page
in some cases, e.g. when an extension uses a special page for creating
new content, and the final name of the content is not yet known
when the EditFilterMergedContent hook is called.
This change will allow special pages to be used in this context.
Change-Id: I5551bff69e3b617a437bd043fdc893dbdcd9f09f
On top of that I changed /history to no longer show the
changes link if it's the first revision of the filter.
As I was on it I fixed the diff selection for diffs like
history/1/diff/2/next where change number 2 was compared
to the last change of the filter instead of the next one.
This probably went unnoticed because the /next action isn't
linked anywhere within the software itself.
Change-Id: Ic28bb696a4dbbb75e0bfcae1843ccefab1a9508a
This changes the AbuseFilter to use Status objects for internal
error handling. This allows for more flexibility in passing error
messages back from hooks and avoids double escaping.
Change-Id: I72e1a6dd7dee19f889fc13b60456e9bfebd5e22b
This makes AbuseFilter use EditFilterMergedContent if support for
the ContentHandler infrastructure is present. This means living
without some nice bits of context, because EditFilterMergedContent
doesn't provide an EditPage object.
This requires core change I99a19c93 to work correctly.
Change-Id: Ibb9d4c9a36b8a199213958b920902e8006c71fe8
If $wgDisableCounters is set, using the variable will result
in a syntax error for an undefined variable.
Change-Id: I136484356506c87ac0e2ede088787e854a0a2fa9
This patch allows the current AbuseFilter to work with 1.19, by only
using MWTimestamp if MediaWiki is version 1.20 or later.
Api still needs fixing, but this will get filters running.
Change-Id: I7c9eaf777d529ce15dfd85761784f9ad1443f2bf
The concept of different AbuseFilter groups had not properly been integrated, but should be now:
- The total number of matches is now group-specific
- .. Which will also fix the emergency shutdown calculations
- And a portion of incorrect code (involving $logged_local_filters) has been fixed (action != group)
Change-Id: I091199a9d74aee47dcb3d8942394a28e0ffd3234
The link should not be shown to users that don't have the right to use it,
like with the tools and import pages
Change-Id: Ie48e61a7de61ab095d621845466aea56b7445f5a
Added two hooks to the AbuseFilter, one that allows altering of the
variables created for a specific user and one for title specific
variables. This a much cleaner way to add title or user specific
variables than using the current general-purpose hooks.
Change-Id: I7374846346dd220b5d0633c11c134030f98bcf00
Patchset 2: Handle more content types
Patchset 3: Change cover letter
Patchset 4: Make it b/c
Patchset 5: Refactor and use previous audience
Patchset 6: Fixed/ minor changes
Change-Id: Ib1d2f9803bc95bb9efd445e3778126d5c3090a71
This patchset will make it possible for other extensions to tap into abusefilter with a custom group, and set different tresholds per group.
See https://gerrit.wikimedia.org/r/#/c/29569/
Change-Id: I21d31bdf28e26f3c830652efc08a247db9f7a86c
* Replace deprecated methods.
* Remove no longer needed function fnmatch().
* Remove superfluous newlines.
* Remove unused and redundant local variables and globals.
* Deglobalization.
* Update documentation.
* Fix incorrect return values or add FIXMEs when in doubt.
* Escape output in a few places where needed.
* Remove unneeded MEDIAWIKI constant checks.
* Fix various JSHint/JSLint issues.
Patch Set 11: Merged https://gerrit.wikimedia.org/r/24701 into
this one per Siebrand's request
Change-Id: I02ba4ce31b6aca5b7324114093f8ece143abc295