Warning: Untested. Looks like it should work based on the data in production
though
E.g. check enwiki afl_id=6426786, old_id=482371851, DB://cluster22/203012734
var_dump( unserialize( gzinflate( ExternalStore::fetchFromURL(
"DB://cluster22/203012734"
) ) )->mVars["new_html"]->mParameters );
Follows up r102497
Bug: T75473
Change-Id: I84305a754a1f8aa1c58edd702380e288de770e2a
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
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
AFComputedVariable::compute() caused fatal errors when trying to handle
non-text content, e.g. in Special:AbuseLog.
For now, we just stub out some variables for non-textual content. Extensions
can still provide values for these using the AbuseFilter-interceptVariable hook.
A real solution requires us to make the Content object available along with the
variable array, or at the very least log the base revision id of filtered changes.
Change-Id: I795549b733f2f418b471223786d206fd8925d8fc
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
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 hook 'AbuseFilter-interceptVariable' can be used
for intercepting any request to recalculate a variable,
and if a handler is returning false the later code
will be skipped. That makes it possible to avoid using
content if the content model is wrong, as it could be
for a Wikibase entity.
The hook uses the same arguments as the hook
'AbuseFilter-computeVariable', thereby making it simple
to move handlers around.
The arguments to the hook are
@param string $method
@param AbuseFilterVariableHolder $vars
@param array $parameters
@param AFPData|array|int|mixed|null|string &$result
Patchset 2: Fix for arg 1 to the hook, it got $this
instead of $this->mMethod
Change-Id: I4944ea612369d6f96319e24c96d97cf9739358c7
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
* 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
Instead pass the Article object from the EditFilterMerged hook to the AFComputedVariable object and see whether the object is present to do a parse operation since other code paths won't pass an Article object
Also simplified the fallback code in AFComputedVariable::compute() to simply continue instead of calling the function again.
ATTENTION! This may break filters that rely on "added_lines contains 'bla-bla'" syntax. They'll need to be replaced with "string(added_lines) contains 'bla-bla'"
