The following sniffs are failing and were disabled:
* MediaWiki.Commenting.FunctionComment.MissingDocumentationPublic
Change-Id: I6075c76d53a899aac56af027f9a956a6b9e6a667
Why:
* The AbuseLogger::insertLocalLogEntries calls the CheckUser
extension to insert the abuse filter log entries, so that
checkusers can see these log entries in the results.
* However, these logs can be inserted on GET requests (such as
when a filter matched a autocreation of an account). This means
that the TransactionProfiler warns about writes.
* Updating the writes to occur on POSTSEND and also silencing the
expectations about not performing write queries should prevent
the logstash spam being caused by the TransactionProfiler related
to this code.
What:
* Make the call to Hooks::updateCheckUserData occur on POSTSEND
instead of PRESEND.
* Silence the TransactionProfiler for 'EXPECTATION_REPLICAS_ONLY'
only for the call to Hooks::updateCheckUserData.
Bug: T359648
Change-Id: I08e1674ff4dca386c046374c77dd31b4b29bb41e
Why:
* An AbuseFilter variable is needed that allows filters to determine
what type the current user is. That is, whether the user is an
IP address, temporary account, named user or external user.
* Currently filters implement this by inspecting the value in
the 'user_name' variable, but this is likely to break when
temporary accounts are enabled as IPs would be hidden.
* Giving a dedicated variable that indicates the type of the user
allows filters to work out this information without having to
know the specific username of the user before performing the
check.
What:
* Add the 'user_type' variable which is lazily computed. It can have
the value 'named', 'temp', 'ip' or 'external' depending on the
type of the user. If the user does not match any of these, then
the value is 'unknown'.
* Replace call to deprecated User::newFromIdentity with a use of the
UserFactory service that is dependency injected.
* Add and update tests to ensure consistent test coverage.
Bug: T357615
Change-Id: Ifffa891879e7e49d2430a0330116b34c5a03049d
This patch solves a pending TODO which is to remove the ::factory()
method from the AutoPromoteGroupsHandler class. If the cache instance
is injected, we'll use it otherwise we'll default to a HashBagOStuff.
Bug: T358346
Change-Id: I2bc414da8733431d1d11025e954282fc7c73aa80
Why:
* In f3c87749b8, the sending of logs
to CheckUser when using a temporary account was fixed. As part
of that change, it was suggested to add a test to verify that
the call to `Hooks::updateCheckUserData` actually causes an
insert into the relevant CheckUser result table.
* This change adds this test as a follow-up.
What:
* Create a test for the AbuseLogger that verifies that an event is
sent to CheckUser and is saved into the DB for an abuse filter
hit. This test is only run if the CheckUser extension is installed.
Bug: T358632
Change-Id: I33ed0810db13e38eacf4e682eb54d4ffcd583084
Why:
* AbuseFilter can send AbuseFilter logs to CheckUser if they are
not being sent to Special:RecentChanges.
* However, if this action is indirectly causing the creation of
an account (such as through temporary account auto-creation),
the log entry is sent to CheckUser before the temporary account
actually exists in the 'user' table.
* This causes a CannotCreateActorException, as the performer does
not exist on the wiki just yet and therefore cannot have an
actor ID until the temporary account is created.
* This exception can happen if the AbuseFilter filter only creates
a log entry and does not prevent the edit, so would not be
necessarily fixed by T334623.
* Sending the logs to CheckUser on PRESEND avoids this, as the
user will exist by the time that PRESEND is run but still allows
any failures to cause an exception which can be seen by the user.
What:
* Wrap the call to Hooks::updateCheckUserData in AbuseLogger
::insertLocalLogEntries in a DeferredUpdate which is set to run
on PRESEND.
Bug: T358632
Change-Id: Ia615fce3e26b88d5457ecc01231044b326b79973
This feature never worked very well, and the original wish
https://w.wiki/7ZsE didn't ask for a 2010 editor solution, anyway.
Rather than have AbuseFilterBlockedExternalDomainsNotification linger in
an unstable state, we remove the code entirely.
Bug: T347435
Follow-Up: I7eae55f12da9ee58be5786bfc153e549b09598e7
Change-Id: I88e87c4e0a2968b892394461b1227f4d15938e8e
LibUp was getting caught out by the false-positive hit to
es-x/no-resizable-and-growable-arraybuffers, so doing a
manual fix to make progress.
Otherwise just whitespace changes.
Change-Id: Ibf20dd2d88613b0a74813c33239e7d0bac682b17
Why:
* When CheckUser asks the AbuseFilter extension for modifications
to rows inserted into the CheckUser tables, the AbuseFilter
extension attempts to get the Filter user via User::newSystemUser
* User::newSystemUser can deadlock if multiple requests to create
the system user are being made at once.
* The CheckUserHander does not need to create the abuse filter system
and instead only needs to know if a given $user is the equal to
the FilterUser.
* As such the FilterUser service needs to provide a way to check if
a given $user is equal without creating the FilterUser.
What:
* Add FilterUser::isUserSameAs which returns a boolean value
indicating whether the Abuse Filter system user is the equal
to a given UserIdentity in the same way that UserIdentity::equals
is implemented.
* Refactor ::getUser to get the username for the filter user in
a separate method, so that the ::isUserSameAs method can also
use this method. Name this new method ::getFilterUserName.
* Add a test for the FilterUser service to ensure consistent test
coverage
* Convert the @covers and @coversDefaultClass annotations to be
a @covers for the class. This is because PHPUnit recommends this in
https://docs.phpunit.de/en/9.6/annotations.html#appendixes-annotations-covers-tables-annotations
Bug: T356275
Bug: T346967
Change-Id: I8a101781bb47612deabb0f2a06a398ac13e860e6
