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
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
* Update rules list view to show global rules toggle, global rules
* Update rule processing to get global rules from memcache, if no
rule exists, get them from the central database and store them in
memcache
* Delete global rule key whenever global rules are updated
* Add filtering for log by wiki on the central database, updated
table definitions to add index on afl_wiki
* Add global $wgAbuseFilterDisallowGlobalLocalBlocks so local wikis
can prevent global rules from locally blocking, removing or revoking
permissions.
* patchset 13: Include recommendations from Tim. Add db updates to
LoadExtensionSchemaUpdates hook.
* patchset 14: forgot to add new files
Change-Id: Id69a9d603f9679f838e8691c651a3e9d8461b422
Adds/checks keys to central memcache instance on throttle actions
to allow for global throttling of events.
Change-Id: Ic4ace6c4aa07990671fe75fbbc1b019a8395fc46
* Store the revision ID associated with a log entry
if the action is successful.
* Expose this as a diff link in the UI.
* Implicitly hide log entries if their
corresponding revisions are also hidden.
* Includes scope for expanding to log entries if desired.
Change-Id: Ie2d43dd1bacf14289fdf0492bb22267590ee649d
The purpose of this change is to allow AFTv5 developers to run a separate list of filters against article feedback actions without issues of cross-contamination and bumping up against the condition limit.
Change-Id: I758795f01eaf3ff56c5720d660cd989ef95764a7
This change depends on I92f57fc2c3189c42157478de14a8d48045a253b5.
This change provides a handler for AbortAutoAccount hook and adds new
action to the filter: autocreateaccount. Every time the AbortAutoAccount
is invoked the filter is executed. This may create some issues with
users which are affected by a filter, because it may be triggered on
every page view. The AbuseFilter relies on CentralAuth session
blacklisting - for each session the filter will be triggered only
once and then the autocreationg of account will not be attempted.
I don't know why AbortNewAccount hook takes as $message argument
a text of message, however AbortAutoAccount takes a name of the
message. This makes impossible to produce a user friendly message
why account creation is not allowed.
Change-Id: Ie3a7ee9210fd884d214ad3132a502a00332c3138
I have introduced a new option $wgAbuseFilterNotifications which
allows to configure the extension to send hit notifications to
Special:RecentChanges or UDP. It uses ManualLogEntry class:
ManualLogEntry->publish( 0, $wgAbuseFilterNotifications )
Log entries are _not_ accessible using Special:Log, that's bug 19494.
Change-Id: Ie4bda2f97aa295c0504ba869ef1a99c7a3d20f70
* Store the revision ID associated with a log entry if the action is successful.
* Expose this as a diff link in the UI.
* Implicitly hide log entries if their corresponding revisions are also hidden.
* Includes scope for expanding to log entries if desired.
