Summary

The oauth_consumer AbuseFilter variable (T298281) is always lazy-computed from the current request's OAuth session, even when AbuseFilter re-generates variables for a past change. As a result, Special:AbuseFilter/examine and action=abusefiltercheckmatch report null for edits that were actually made via an OAuth client (and would report the *examiner's own* consumer ID if the examine request itself is OAuth-authenticated, e.g. a tool calling the API). This makes it impossible to test filters that use oauth_consumer against past edits — the main workflow for developing exactly the kind of filter this variable was created for. Live filtering at edit time is not affected.

See the original feature request: T298281: AbuseFilter should allow filtering based on the use of a specific OAuth application.

Technical notes

\MediaWiki\Extension\OAuth\Backend\AbuseFilterHookHandler::onAbuseFilter_generateUserVars() receives a ?RecentChange $rc parameter but ignores it and always reads the consumer ID from the session's provider metadata. When $rc is non-null, the handler should instead resolve the consumer from the RC row's change tags (ChangeTagsStore::getTags() on rc_id) using the existing Backend\Utils::parseTagName() to decode the OAuth CID: <id> tag. MobileFrontend's user_mobile handler (MobileFrontendHooks::onAbuseFilterGenerateUserVars()) implements the same live-vs-RC split and can serve as a template. Note that edits by owner-only consumers are not tagged (and the variable is intentionally unset for them live), so behaviour stays consistent between the two paths.

Acceptance criteria

• Examining a past change made via a (non-owner-only) OAuth consumer shows that consumer's ID in oauth_consumer instead of the value derived from the examiner's session
• Live filtering behaviour of oauth_consumer is unchanged, covered by PHPUnit tests for both code paths