We do not validate the param, and instead only check if it was
specified. In the specific case of ViewHistory, specifying as "filter"
something invalid for a title (e.g. with a + inside) will throw an
exception, seen in production.
Change-Id: I636b4e56f39282593c737ace1d6ff2d90900d997
The case default was recently added, but didn't take into account that
"false" is valid too. Noticed by chance just before the train rolled
out.
Change-Id: I67ca475fa16ea449820f8c735531c2cc1b0ec975
Now that Parser errors are on logstash, I noticed a huge spike of errors
on Wikimedia Commons, about 35000 per hour. They seem to be due to 2
broken filters, but id doesn't say which ones.
Change-Id: I8510319c075520f9a893cd7d56f2e30679e249ba
Tagging doesn't work for account creations, and probably never did. This
is because we used a wrong identifier for such actions. This patch fixes
the problem, although in the long term we should find a smarter way to
apply tags.
Also, clean AbuseFilter::$tagsToSet if the action will be prevented.
Depends-On: Ia8e38ba25d1989fe71714d2b76891c4587921466
Change-Id: I8edcca17ecdcf71397cc9b0d101e8b13ac112047
This may solve several issues, see T176291#4105438 for further details.
Bug: T191430
Bug: T176291
Depends-On: Iebbdeac7898b35beea79aa3d0cdf9d0fb265d726
Change-Id: Ia8e38ba25d1989fe71714d2b76891c4587921466
When updating the abuse_filter_history table, the sequence to use is the
one on afh_id... And we were using the af_id one since 2009.
Change-Id: I3e291c780119d74be5f47e745a8de13bda85486b
*Don't reuse a message (which is bad), instead add a note for
translators. We can also move it on translatewiki.
*Don't show the AbuseLog link if the user cannot see the AbuseLog.
Change-Id: I4ce73b2160275fdc4b0b7bec722471696d8c6a4d
As follow-up of I10b1fd2d9bdfe518089c053d77fef568170ecb65, use
'AbuseFilter' instead of 'AbuseFilterDeprecatedVars' as channel name.
Raise level for null-title filtering. Since with a null title
several things are likely to break, a warning is more appropriate here.
Tweaked the message as well, to include the bug number and to avoid
pointlessly including the title (which is null).
Lower the level for stashedit hit/miss (as it's really spammy and not
that useful right now).
Use 'abusefilter' instead of 'AbuseFilter' for statsd so that everything
has the same prefix.
Also raise the level for parser exceptions and unrecognized
consequences.
Change-Id: I1f9988155e924232b201281795cd322636da8082
Follow up to Idbb3a70d08a195dfa21422e07f593d1eeba4521d
This also fixes the fetching of text for the stash edit code path
which was missed by the previous patch.
This now also uses the full old text in the variable holder.
Bug: T213453
Change-Id: Ib80bc6385ebb5dd82bb1a384dd0e162608bfcbfa
The RecentChange class has several getters and setters for the $mAttribs
property. Although the property is public, it's saner to use such
methods.
Change-Id: Ie8e37e80fdcf2917ee0e87b2a409f0afb91a4f92
When all the other patches will be merged, this workaround won't be
necessary, and by removing it we're finishing the first phase of
variables migration. Which could also be the only one if we decide not
to go on and remove the old ones.
Bug: T173889
Depends-On: I5c370b54e6516889624088e27928ad3a1f48a821
Depends-On: I6576497feaf6d2c475ee33a91feb6a640e2c20fe
Depends-On: I87a48fdc8b392b25eb02807e8d0f712d0a399ece
Depends-On: Ib29eb15c1a51c037d036be8dc1541d96ea4b174b
Depends-On: I909a99e80a895a9b009c33ea72e8e0a4ea0a1375
Change-Id: If5f238cddb41ef92b141e36b4f2f15fd4cc86476
This is for adding variables which can be computed even without an
ongoing action. Currently, we don't have any, except for timestamp (but
that's a bit special). Other extensions could. For instance, we'll be
able to expose the content of the spam blacklist.
Bug: T211680
Change-Id: Iba59fe8d190dd338ecc8cfd682205bce33c9738b
Otherwise calling bufferTagsToSetByAction multiple times makes the list
grow, and IIRC the core doesn't call array_unique on the tags to apply.
Also clean the list after applying tags.
Change-Id: Iebbdeac7898b35beea79aa3d0cdf9d0fb265d726
The variable was disabled with I7f13773766e12f3d4b86451fdf3ae23e067ac373
in 2016, but not in the same way as old_text and old_html were disabled
in 2009. This patch uses the methods introduced with
Ife168522e6b1d8eb94ebbb8a16ae8831ec1dc497 to disable minor_edit in a
standard way, so that it won't be showed in new AbuseLog entries, and
won't be usable when writing filter syntax.
A warning will be emitted if a pre-existing filter is using it, so that
we'll be able to completely disable it in the future.
Change-Id: I5ad5219ee19a5e6ba2bfdffb4e0aad63c8951491
In T209565#4826952 I discovered that if the "abusefilter-blocker"
message is an invalid username, we silently end up without a system
user, thus risking to break something. Instead of silently failing, emit
a warning and use the default name. As I wrote in the code comment, we'd
better avoid throwing, because the message can be modified by anyone,
who could then break the site.
Change-Id: Ifa866bd9676945bf94e7e481adf6ad0d6cf4370c
This partly reverts If72b18bedac5e580487406e696aea1fd172ae45b. While
it's true that we don't need every filter, that method is public and
other code may need fields that we don't need. This way we can encourage the
use of this function (which caches the result) instead of direct DB
access.
Also, the method can currently accept global filters passed as
"global-<integer>", but saves them to cache with the same key as local
filters (i.e. local filter 15 and external global filter "global-15" are
both saved in AbuseFilter::$filterCache[15], which could lead to subtle
bug).
Change-Id: Ieb04f019453033c275e211cfc9fd68d5d7c392ef
My final testing unveiled 4 problems, see T209565#4780868. Testing again
after this patch yields the expected outcome.
Update: A fifth problem is that we cannot disable throttling if throttle
groups are empty or fully invalid: that case is similar to the one with
invalid rate, the throttle limit is never reached and thus throttle just
doesn't work. Instead, ask users to fix it by hand.
Bug: T203336
Bug: T209565
Change-Id: Id03c9880f60764efc596ac40b8662087fdb30550
We have two situations where we try to execute filters without a title.
However, the code doesn't handle it correctly: some points expect $title
to actually be a Title object, and we also pass it around using a hook
which explicitly says it always pass a Title. This patch adds two debug
points to help understand why we end up with null titles, so that we can
fix it upstream.
Bug: T144265
Change-Id: I35bfc483a0c69a5cbd38eae8ba299189955fa1ec
Currently it barely has any reason to exist, as it's a single-line
method. This patch moves there the global state, and also changes the
signature to allow shorter calls.
Change-Id: I7851fa41cbd96912b3859319ba97a501b1cbaa57
AbuseFilter::buildFilterLoader is only used in ViewExamine and
ViewTestBatch, so this patch moves it to AbuseFilterView and makes it
non-static.
Change-Id: I7f11cfd7ac81e536492eb59c40da7c14771cee2b
This is a first step towards MCR support in AbuseFilter. The textual
representation of all slots is concatenated. Since AbuseFilter uses
getTextForSearchIndex to determine the textual representation of
content, blind concatenation should not break any assumptions
made by AbsueFilter rules: this naive approach is no worse than
AbuseFilters handling of non-textual content in general, and should
work fine for textual content.
Bug: T209291
Change-Id: Ic141085cad2e11bfe106fe83dafcb35ac31206ba
For several reasons:
*We're not really checking permissions (and the hook previously used is
meant to be used in such case)
*We'll show a cleaner error message (i.e. without the "You do not have
permission..." part)
*Filtering will happen closer to the actual move
Bug: T208907
Depends-On: I4733724075b7514e9db59e7be772d9409aa9da87
Change-Id: If88f736a446247f8b4b13c055c641d56f544d1ea
While editing filters, sometimes it happen that you make some change,
forget about it and then reload/close the page, and no warnings will be
issued. This patch makes use of the core module used for normal page
editing to display a warning if trying to leave a filter editing page
with any unsaved change (both to the filter pattern or other form
elements).
Change-Id: I78d79215565d5c82028b1a2a4276497ccbffdea2
Later, we will add a new POST request which will allow retrieving
the private details; it will have a mandatory "reason" parameter,
and will result in a log entry in the private details access log,
just like the web interface.
Bug: T210329
Change-Id: Iaca492371f48fecf543268c179a651841ed12c3f
Signed-off-by: sbassett <sbassett@wikimedia.org>
Those two global config variables were removed more than 2 years ago, in
I790d39c2849922d7daf7479f298cd90cf30af129. Nothing else in the code
references them, so we can just remove the warning.
Change-Id: I427d06a80131447ea64064f45e84349f93e72cca
This is a follow-up to Ic3bc6e36506973b19a9b1bcecbc1a5080faed2ec. I
believe it's important to specify how many recent actions we're looking
at, and I also think it's not nice to rely on a variable amount of
actions to determine whether a filter should be throttled. Also, require
a $group parameter in filterUsedKey (we always pass one, and there's no
reason not to).
Change-Id: I0384d3f1913ead593f605248950606c81c8f8542
Some public/protected methods are actually meant to be private.
This patch is only a first step: other methods need to be made
protected/private.
Change-Id: I432c65d333b4dc497532679750f44b2c7e078bf0
