Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: I48fcc02c61d423c9c5111ae545634fdc5c5cc710
In some cases, evaluation short-circuits when getting a list of
used variables resulting in an incomplete array of variables. This
subsequently causes issues when using those arrays for validation
checks (eg. if protected variables are used).
- Force full evaluation by setting `mAllowShort` to false
Bug: T364485
Change-Id: Idf2112d9ebf63846cde3ce9b8a8ade0ed909505d
First patch in a series of dropping the old columns.
Wikis now need to run the maintenance script (e.g., via
update.php) prior to serving this commit.
Wikimedia wikis are already on SCHEMA_COMPAT_NEW stage.
Bug: T188180
Change-Id: I86ec2b816eed17b62bf02bfd085570f132011b3e
Any filter using protected variables must be marked as protected via
the a checkbox on the filter edit form. This checkbox should not be
visible to users without the right to use protected variables.
Bug: T364485
Change-Id: If2c4b8f50f447e951d820798f181839d10501aa3
The UI/UX for acknowledging a filter will be protected/is protected
could be clearer. The checkbox implemented currently doesn't make
it clear that the acknowledgement is mandatory and filters that are
already protected allow for the checkbox to be unchecked even though
that doesn't reflect that the filter cannot be unprotected.
- Update copy for the protected filter acknowledgement to make it clear
that it's a mandatory acknowledgement, not an optional one
- Update copy for the error that shows when a filter that should be
protected doesn't have the acknowledgement checked
- When a filter is already protected, disable the acknowledgement
checkbox to indicate this is not mutable
Bug: T364485
Change-Id: I667fcca4511dff1ac3ca69930c5b5e5eb5001787
When a user without the right to see protected filters visits
Special:AbuseFilter/history/<ID>, show the permission error
message for protected filters.
Before this commit, the error message for hidden filters is
used instead, even if the filter is not hidden.
Bug: T364465
Change-Id: If2573fe256a7e29e8184feaf2f0622659706fd56
- Add a basic checkbox on the filter edit page that must be checked if a
filter uses a protected variable to ensure that the user is aware that
their filter will also become protected
Bug: T364485
Change-Id: I7c7652f7d1a81223229b839ff7eee5da4af74c8a
Some exposed variables (eg. `user_ip`) used in filters are sensitive
and need to only be available to restricted groups of users.
Back-end changes:
- Add `AbuseFilterProtectedVariables` which defines what variables are
protected by the new right `abusefilter-access-protected-vars`
- Add the concept of a `protected` variable, the use of which will
denote the entire filter as protected via a flag on `af_hidden`
New UX features:
- Display changes to the protected status of filters on history and diff
pages
- Check for protected variables and the right to see them in filter
validation and don't allow a filter to be saved if it uses a variable
that the user doesn't have access to
- Check for the right to view protected variables before allowing access
and edits to existing filters that use them
Bug: T364465
Bug: T363906
Change-Id: I828bbb4015e87040f69a8e10c7888273c4f24dd3
Protected variables will cause the filter using them to become
protected as well. `af_hidden` can be used to track this flag,
as it is a TINYINT and can be converted into a bitmask with no
schema changes.
This is not a backwards-compatible change, as now all checks must
check the `hidden` flag specifically or otherwise will be cast to
true if any flag is set.
To support this change:
- "hidden" is considered a flag set in the `af_hidden`. This is a
change in concept with no need for updates to the column values,
as there is currently only one flag in the bitmask.
- `Flag`s store the bitmask as well as the state of single flags
and can return either.
- Any checks against the `af_hidden` value no longer check a
boolean value and instead now check the `hidden` flag value.
Bug: T363906
Change-Id: I358205cb1119cf1e4004892c37e36e0c0a864f37
After temporary accounts are enabled, filters that rely on an ip
in the `user_name` will fail (eg. `ip_in_range` and `ip_in_ranges`).
To keep these filters working:
- Expose the IP through another variable, `user_unnamed_ip`, that can be
used instead of `user_name`.
- The variable is scoped to only reveal the IPs of temporary accounts
and un-logged in users.
- Wikis that don't have temporary accounts enabled will be able to see
this variable but it won't provide information that `user_name`
wasn't already providing
- Introduce the concept of transforming variable values before writing
to the blob store and after retrieval, as IPs need to be deleted from
the logs eventually and can't be stored as-is in the amend-only blob
store
Bug: T357772
Change-Id: I8c11e06ccb9e78b9a991e033fe43f5dded8f7bb2
This removes the last usages of the problematic open/closeElement
from this codebase.
One actual issue gets fixed: Some of the <th> floated around without
a <tr>. That's technically invalid. Luckily the browsers are flexible
and show it correctly. Visually nothing changes.
Similarly <th> should be wrapped in a <thead>. This wasn't done
before.
Change-Id: Ia45096670888173e49f9c25e72f429f0961b75ae
This issue exists ever since this code was added in 2009. Note how
this element is invisible anyway. The non-breaking space is never
seen. The purpose of this element is to act as a container for a
debug result that will be put into this container via JavaScript.
I confirmed this still works fine without the placeholder character
being there.
The problem here is that this HTML entity is double escaped because
of the element() function. That would need to be a rawElement() call
or we can just remove it.
Change-Id: Id560f392be4cc2106a7ac224309c8b605bec3f6c
Why:
- We want AbuseFilter to able to require a CAPTCHA if an action
matches conditions in an AbuseFilter
What:
- Implement the ConfirmEditTriggersCaptcha hook, and check to see if
the CaptchaConsequence set a global flag that indicates if we
should show a CAPTCHA
Depends-On: Ie87e3d850541c7dc44aaeb6b30489a32a0c8cc60
Bug: T20110
Change-Id: I110a5f5321649dcf85993a0c209ab70b9886057c
This solves two issues described in bug T360909:
* Usage of unsafe characters that have to be
manually reviewed in translations.
* Incorect display of some functions and
operators in RTL UI languages.
It also reduces the translators' need to copy
those operators and functions, which are always
identical to English.
Finally, this patch adds those consistently to all
the messages. Some messages didn't mention them
for an unspecified reason, and now they are mentioned
everywhere.
Bug: T360909
Change-Id: I3283c91b6b1d5fe9b48b1477cd454d9def3a7ded
A custom API error code and data similar to those used when an edit is
blocked by a normal AbuseFilter filter were accidentally added when
the feature was introduced. They should not be there, as the blocked
domains feature is not a normal AbuseFilter filter.
Hopefully nobody is relying on the format of this API response yet.
This commit changes the action=edit response for this case from:
{
"error": {
"code": "abusefilter-disallowed",
"info": "The text you wanted to publish was blocked by our filter. The following domain is blocked from being added: example.edu",
"abusefilter": {
"id": "blockeddomain",
"description": "blockeddomain",
"actions": "disallow"
}
}
}
to:
{
"error": {
"code": "abusefilter-blocked-domains-attempted",
"info": "The text you wanted to publish was blocked by our filter. The following domain is blocked from being added: example.edu"
}
}
Change-Id: I61ccc8f44b63e5cd0f11b1fe9a00ff60104a6249
Instead of having separate methods for each variable,
have one method which can work not only with "_links",
but with any array of strings.
Change-Id: I05f1b1cbd15f283b314c72259f183f7788e4e214
It is a common pattern to avoid SELECT * and use the fields used by
the application to avoid loading to much data into memory and maybe use
performance benefits when fields are covered by index.
Change-Id: I08a399f1b6a66442317b151be5386c9d2485f1fb
Constructing a Status like this does not make sense (and I want
to deprecate it in I0675e557bb93a1c990fa923c50b9f6ee8a9836c8),
because the parameters are ignored by most Status methods:
$error = Message::newFromSpecifier( 'abusefilter-blocked-domains-attempted' );
$status = Status::newFatal( $error, 'blockeddomain', 'blockeddomain' );
But it worked here, because FilteredActionsHandler::getApiStatus()
used a deprecated method that allowed inspecting them.
I feel like this code in BlockedDomainFilter has been added to make
the tests pass without thinking about what it actually does, which is
to output a bunch of useless incorrect data in API errors.
I'm not sure if we can remove that now without breaking API
compatibility, so add the useless data in FilteredActionsHandler
instead, closer to where it's output.
Change-Id: Ic12241bd3029bc1b0e7a0023689a2be35ccd30a8
From Status class documentation:
> The recommended pattern for Status objects is to return a Status object
> unconditionally, i.e. both on success and on failure -- so that the
> developer of the calling code is reminded that the function can fail, and
> so that a lack of error-handling will be explicit.
Change-Id: Ie6a55e297a35374fbdef880dd40e65f5cd00b6bf
