It's totally pointless to recreate all variable names, since we already
have them in builderValues. The only exception is for _restrictions
variables, although they should be handled in builderValues too.
Change-Id: I156ebb1e6e590d09ded093a23d19c0d635a503bf
This ensures that each repository's "npm test" command is fully
independent of wherever it might be in the filesystem.
Bug: T206485
Change-Id: I4b9598d41b2fe01703b89914f9c1a470ed1a9cf2
Instead of only the first one. This is quite hacky, but I don't have
much time right now, and this script is written in the spirit of JFDI.
Bug: T209565
Change-Id: Ic12ff21dd41b619bea9c71001555fd4d6299e58b
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
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
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
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
For the docs part: make it clear how things work there. For the code
part, these are mostly style changes: shorter variable names, no
unnecessary parameters, make the method private, use clearer variable
names.
Change-Id: Ic3bc6e36506973b19a9b1bcecbc1a5080faed2ec
