Currently it checks if the filter is set to hidden, and then
requires the private permission to view it, which is intended
for private data (like IP addresses), not hidden filters.
Change-Id: Iff8f9edf2466050aeadf3907dcff5464e179ff68
I've changed the JS of the AbuseFilter extension to match our
coding conventions and made it use mediaWiki.Api(). Furthermore
I fixed several error handlers and made some things nicer in
general while trying to not change the user appearance.
I've tested the changes as good as I could (I'm pretty sure everything
works).
Change-Id: Iaa0f99367bd7e0bfaf7249dcc9ac9ce9881b46e1
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
