Most notably, make it not use additional DB tables to test global
filters. Instead, just pretend that the local database is not local (via
config) and "hide" local filters with a simple test-only flag in
FilterLookup.
Change-Id: Ib431dbf6c9d84978ee84e7f0671cfcbf8a54d7a2
I'm planning to add support for bypass and regex-based blocking which
means it'll grow a bit. So let's give it a dedicated class.
Bug: T337431
Change-Id: I5a6fe2fd2f1efdebd8cada0ba6c481341f830e27
Unlike what the 20-year old source comments in UrlUtils.php would
have you believe, parse_url() works fine nowadays, including for
protocol-relative URLs and indeed lots of prod code uses it directly.
The class still has some convenience value for case where you need to
expand or manipulate URLs, but for the common case of extracting a part
of it, you really don't need it.
Test plan:
$ php phpunit.php ../../extensions/AbuseFilter/tests/phpunit/integration/FilteredActionsHandlerTest.php
Bug: T337431
Change-Id: I1e76d2f5aef65365743214530faba656325b965a
This is basically copy paste of SpamBlacklist logging with the added
extra bit of what triggered the hit.
Bug: T337431
Change-Id: Ieb9e3ca615af88ab56735b56e24c80c42a68d478
Regarding array building: Instead of adding to array with
$array[] = 'foo' and then doing array_flip(), simply do
$array['foo'] = true;
Regarding tests: I originally wanted to create a unit test but I ended
up mocking so many things that it wasn't worth it and the config variable
is globaly which first we need to clean up after deployment is done.
Bug: T337431
Change-Id: Iac8dca7078668ee3441d19b6aafe499c1aa0d732
We will have a pretty large list of blocked domains that we need to
swift through in each edit for any added domain. In order to cacth
subdomains being added, we have to do all sorts of complicated
operations and string search in large set of strings which is quite
slow. To fix that, let's simply pretend a user who has added
foo.bar.com, also added bar.com and com and do exact match in array of
strings making it much faster.
h/t Krinkle for the idea
Bug: T337431
Change-Id: I96795ed7d1a25f051db0b591dde21b032b138ded
For now, we will revisit this in the future. Specially if the
communities think otherwise.
Bug: T337431
Change-Id: I2847264eba9a3cc4fc47a22eacb523199015f9e7
This makes raw page editing safer, and potentially enables opening up
access to less restricted user groups.
Bug: T337431
Change-Id: I14f21003a551f34b6e524e9b229613e79b0e5a70
It is behind a feature flag. Improvements on it can happen in follow
ups. The patch is already quite massive.
Bug: T337431
Bug: T279275
Change-Id: I3df949c4d41ce65bb4afa013da9c691ac05fc760
* Set the same block expiry for temp and anon users
* Don't block autopromote for temp users; they can't be autopromoted
* Bail early from CheckUserHandler if the user is temporary
Bug: T335062
Change-Id: I6b72537f568c4c70a0b86f1825ea30b767f5634a
This patch migrates abuse_filter and abuse_filter_history tables
to new actor schema.
MigrateActorsAF was copy-pasted from core's
maintenance/includes/MigrateActors.php before removal (ba3155214).
Bug: T188180
Change-Id: Ic755526d5f989c4a66b1d37527cda235f61cb437
Use the very new getPrimaryDatabase and getReplicaDatabase.
We skip FilterLookup and CentralDBManager in this patch.
Change-Id: I22c6f8fa60be90599ee177a4ac4a97e1547f79be
Hook on to CheckUserInsertPrivateEventRow and CheckUserInsertLogEventRow
to override the IP, XFF and User-Agent string when the user is the
abuse filter user for log events.
These two hooks are being added as log entries are being removed from
cu_changes and added into two new tables. Because the columns and their
names are different for these tables, reusing the same hook won't work
for callers that rely on setting values for a specific column name.
Edits and log entries performed by the abuse filter user need to be
marked as being by the software (and not using the IP, XFF and
User-Agent provided in the main request).
These hooks will not be run until the appropriate config is set to
write to the two new tables. Until that point using the one currently
defined hook will work for all actions.
Bug: T324907
Bug: T44345
Depends-On: I7c7754323ade9a8d96273c1742f30b1b5fbe5828
Follow-Up: Idd77545af94f9f9930d9ff38ab6423a72e680df9
Change-Id: Id78417e9d95220946f110afbe1430df5b3bb4f4f
Add RecentChange as a optional parameter to the code that hooks
on CheckUserInsertChangesRow as this hook will soon provide a
RecentChange object if this row was triggered by a RecentChange.
If this row was not triggered by a RecentChange, then this
parameter will be null. This needs to be added before the parameter
is added to the definition of the hook in the CheckUser extension
as the tests will fail if all usages do not already have the new
parameter.
Bug: T324907
Change-Id: I44e54a3fca5558a1cb8d8f06a3990ded863454bc
Change the IP to 127.0.0.1 (to indicate an internal IP), and blank
the XFF and UA when the performer of an action being logged by
CheckUser is the abuse filter user. Actions performed by the abuse
filter user can only be initated by the software, and as such should
not use the request's IP, XFF and UA. Also test the newly added
code.
Bug: T44345
Depends-On: I28acaaebd2d0067b700da0930e7b7ba924fa5c1c
Change-Id: Idd77545af94f9f9930d9ff38ab6423a72e680df9
They are unused in Wikimedia code (finally).
Change-Id: I74c81d950d992552d3edf184b5eecc46e5e2c567
Depends-On: I62533e21d2bc1a22c3fcba4c7c650ca9d95700ef
Depends-On: I95ce9897d89213e358c436135278b729f0adc3a2
- Define it with the extension.json key, instead of using the
registration callback
- Inject the services it needs
- Replace direct User instantiation with UserFactory
- Move log subtypes to extension.json as well
Change-Id: I86a761c7fa844b1f417b974798373622a15f6411
Note that this doesn't have to be applied in WMF prod, since the indexes
are already correct there.
Bug: T291725
Change-Id: I7fcee0581f469e0d7ada43d1f30f31061c5bf5c0
On second thought, no need to keep the migration script now, since it's
unusable anyway.
Also remove an usage in SpecialAbuseLog, likely a rebase artefact.
Change-Id: I938924b3617ef30046d8317e68a101ed2c1883d3
Sharing a handler class with UserRenameHandler means that attempting to
merge users fails due to a missing interface if AbuseFilter and MergeUser
are installed but Renameuser is not installed.
Change-Id: I1244ab1c446840ff2648248f943d7fc784b889a7
Follow-up I574bda15f0f5c92a7d97a6e3150981b8f97ee7fc
Apologies for not noticing before:
If somebody hadn't already added the afl_filter_id column, the
rename-indexes patch would try to rename a non-existing index
(filter_timestamp_full and fail). So put rename-indexes after the other
patch.
Then, for the afl_filter_id patch, check the column and not the index.
We were checking the index because it's the last thing that the DB patch
does (so if the index is found, we can be certain that the patch was
fully applied). However, now that renaming the index happens afterwards,
if somebody had already added afl_filter_id (with the old index name),
running the updater would try adding it again, because the new index
name isn't found (as it's renamed later).
Change-Id: I0250a7c187202facd932c160ace57930db510f64
The only user we were worried about has now migrated to this; it auto-
ran in other installs just fine, so let's proceed.
Bug: T269712
Depends-On: I2b905f1e13ec13ec94d33527803c91c04b491eb2
Change-Id: Ie7d6bc95ebc871b0effee069e2146f2750d5f408
