Allows for more broad filters to check for a given right, rather
than having to check against multiple groups, which becomes useful
with global groups.
Bug: 60191
Change-Id: I95b5477d6d868d4b83bcd98e779e6d535aa755b3
If multiple filters all add tags to an edit, make all of them be added
rather than just one of them.
Bug: 66387
Change-Id: Ib666c2765718d7d0603921ab94d22a7d51cbd3d2
* Due to the nature of this code (a throttle) it will likely slam the DB,
so push it after the end of the main transaction.
bug: 60600
Change-Id: I48895358deaa1b951d849eeee14c7126cfa25ec8
The text areas for the table row had only 5 rows, which is a lot less than
the default number of rows.So now the number of rows in the testing textarea is changed to 15.
Bug: 59869
Change-Id: I9f221e7a49473ae1d473333f7ecf26235366d257
I'm not really sure why it exists; I assume to minimize overhead of init'ing
multiple AbuseFilterParser objects that would be exactly the same.
However, checkConditions() - which checks one specific condition - is not really
an "endpoint" you will want to call in <your-extension-that-uses-AbuseFilter>.
You're more likely to call something higher-lever (like
AbuseFilter::filterAction, which will take care of fetching all appropriate
filters, as well as run them through checkConditions, and much more). This will
trickle down to ::checkAllFilter, down to ::checkFilter, which would eventually
call ::checkConditions with the 'keepvars' argument.
Basically, unless you're re-implementing much of AbuseFilter yourself, you won't
get to pass anything other than 'keepvars' to checkFilter.
As a result, even though you may call AbuseFilter to call on multiple different
vars, it will re-use the same parser with the first vars.
I'm proposing to drop the 'keepvars' and just keep the vars around instead.
checkFilter can compare previous vars with new vars, and only init a new Parser
if the vars are different.
Change-Id: I96ccc60c77f3cdbb82c0f9f16782a1a44ffb1592
...otherwise it doesn't work.
This change add 2 checks for object caching, one for the filter
configuration interface, and one for the actual throttle checking.
Bug: 50894
Change-Id: I89ebcc6ff7d91d3a9ad8e744c0c4ff3e33e3b673
If AbuseFilter::filterAction changed $wgTitle, we need to reset it back
to the old value before returning.
And for good measure, we also need to check the main RequestContext to
make sure it didn't cache the bogus $wgTitle on us.
Bug: 53498
Change-Id: I4d706a1ee07f0b171f98e7d558d7be27e6759614
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
