Remove the use statement for MockAuthorityTrait, which is unused.
We can't use it because SpecialAbuseFilter checks permissions on
the user, not the authority.
Change-Id: I2baca5753dd9e21aa90b6856c5850d1100eda4d5
Why:
* The ProtectedVarsAccessLogger::logViewProtectedVariableValue
method creates a debounced log entry for accessing protected
variable values.
* This log can be created when a user calls the 'abuselog' query
API. This API query is made using a GET request.
* Because the ProtectedVarsAccessLogger creates the log
when it is called, the TransactionProfiler raises a warning
about writing to the primary DB on a GET request.
* We should address this warning by creating the log entry on
POSTSEND, in a similar way to how the CheckUser extension
creates CheckUser log entries.
What:
* Wrap the call to ProtectedVarsAccessLogger::log in
::logViewProtectedVariableValue with a DeferredUpdate callback
that is run POSTSEND.
** As part of this, the expectations that the code only uses the
replica DBs are silenced inside the DeferredUpdate as the
PostSend-GET expectations do not usually allow for writes.
The only other method would to be create the log via a job,
but we want the log creation to occur quickly and reliably.
Bug: T379083
Change-Id: If14e65b27b0bdd4fd0b99319024ffa281bf44656
- Clarify that to use protected variables in a filter, they must be
enabled and will cause the filter to be considered protected.
Bug: T377553
Change-Id: I69b879f12cfe76e6fff0080dd93024d6bd29159d
Conditional set of variable is not easy to read.
Instead set the variable to null before try/catch
Reported by a new phan plugin (2efea9f989)
This bypass a false positive from phan (T378271)
Change-Id: I037efe8465747b8c915405f38546fc1ea4405a03
Implicitly marking parameter $... as nullable is deprecated in PHP
8.4. The explicit nullable type must be used instead.
Bug: T376276
Change-Id: I303342cf1a002d5f0afc77ce147ce9453ea5282e
Parent class constructor gets type-declaration in 1145328459
Remove simple doc-blocks without further information
Change-Id: I5d2179af0c7b826ca48df239152412205702cd77
Why:
- For account creations and account autocreations, the user_name
property is deliberately unset, to avoid displaying the IP address of
an unregistered user. Instead, `accountname` is set with the newly
created account name
- For logging that someone has seen a protected variable value, we need
to record the username that was seen
What:
- Use `accountname` as a fallback in case `user_name` is not set, when
logging protected variable access
- Update tests to cover this case.
Bug: T376885
Change-Id: I688a3529fac0ad8455977a0cfdb950f0105f550d
Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: If80031678a474157e4cc78a3d3621dab53aded67
- Define `abusefilter-protected-vars-log` as an available right as
it wasn't already
- Give the `sysop` group the `abusefilter-access-protected-vars` and
`abusefilter-protected-vars-log` rights
Bug: T369610
Change-Id: I44d3824e3d47ad94e8a94e185997c4a8e9d50199
Depends-On: Id8898c17396af0f59ef2d82967e7d85ae4f0cd88
