- 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
- abusefilter-blocked-domains-intro: link to Special:Log/abusefilterblockeddomainhit
- log-description-abusefilterblockeddomainhit: link to Special:BlockedExternalDomains
Bug: T376506
Change-Id: If21c6e2de8b9d524d5299487f58a09d2a8d53720
To hint to translators that gender can be used,
and to avoid warnings on translatewiki about
missing parameters.
Change-Id: Ie9523527d1ce138f978145ddaa565137a7b34ab1
Like CheckUser, AbuseFilter should also log when specific protected
logs are viewed.
- Add support for debouncing logs to reduce log spam
- Log when AbuseFilterViewExamine with protected variables available
is accessed
- Log when SpecialAbuseLog with protected variables available is
accessed
- Log when QueryAbuseLog with protected variables available is accessed
Bug: T365743
Change-Id: If31a71ea5c7e2dd7c5d26ad37dc474787a7d5b1a
CVE-2024-PENDING
Why:
* The 'abusefiltercheckmatch' API allows callers to match
arbitary filter conditions against existing AbuseFilter logs
* The API does not check if the performer has the ability to
see the log details for the given filter, so can allow a user
to bypass hidden and protected visibility settings.
What:
* Call AbuseFilterPermissionManager::canSeeLogDetailsForFilter
before attempting to match a filter against a given AbuseFilter
log.
* Add a test to verify that this security fix works.
Bug: T372998
Change-Id: I4a2467dc4e0d1f8401d5428a89c7f6d6ebcdfa70
- Fix an issue where if a user didn't have view permissions they could
get the preference check error (a preference they wouldn't have) on
SpecialAbuseLog
- Fix an issue where the `change-access` hadn't been updated to the used
disabled/enabled log types
- Fix an issue where a ProtectedVarsAccessLoggerTest test wasn't
correctly using the data provider data
- Improve naming since ProtectedVarsAccessLogger exists in its own test
file instead of being a subset of tests on AbuseLoggerTest
Bug: T371798
Change-Id: I53f22855e63d9e1339361a5c9ee7886e0f74714a
This change is needed to unblock a change in core to the markup.
(I0195d4b0f790f6595cc626a6db96b4fc6380a0f4). The current markup
in core is loading additional CSS styles to support legacy
markup.
Bug: T360668
Change-Id: I4bd1a8a9d4eda1b3e89d067d6671d3f8bad4f584
