Page MenuHomePhabricator
Create Task
Maniphest T307827

Missing abuse logs of Special:CreateLocalAccount actions
Closed, ResolvedPublicBUG REPORT
Actions

Description

List of steps to reproduce (step by step, including full links if applicable):

  • Create an private abusefilter that blocks creations and autocreations of usernames with certain pattern.

Example filter rules:

(
    action == 'createaccount'
    | action == 'autocreateaccount'
)
& (
    rx := "some pattern";
    accountname irlike rx
)
  • Set action on triggering to warning and prevention.
  • Create local account (Special:CreateLocalAccount) for a global account which matches that pattern.
  • Caught by the filter.
  • Check abuse log and see the log (appearing as the account creating its local account, instead of the sysop)
  • Go to Special:CreateLocalAccount and create account for the same or other global accounts that matches the pattern.
  • Caught by the filter again.
  • Check abuse log and no new log occurs.
  • Repeat the creation after 2 hours.
  • Caught again but new log entry appears.

What should have happened instead?:

  • Abuse logs for trials after the first trial should appear.

Other information:
Problem was first found on zhwiki (AF194), then reproduced on wikidata.beta.wmflabs.org by User:Stang (AF3).

Related Objects

Event Timeline

Tigerzeng created this task.May 7 2022, 1:57 AM
Restricted Application added subscribers: Ericliu1912, Stang, Aklapper. · View Herald TranscriptMay 7 2022, 1:57 AM
Tigerzeng renamed this task from Special:CreateLocalAccount actions logged as autocreateaccount in abuse logs to Missing abuse logs of Special:CreateLocalAccount actions.May 7 2022, 1:58 AM
Tigerzeng updated the task description. (Show Details)May 7 2022, 2:00 AM
Stang added a comment.May 7 2022, 2:12 AM

Co-author addition:

  1. Create a filter on Wikidata beta cluster (it was private at that time) - just a normal filter blocks creation for account contains string on9 inside username
  2. Go to Special:CreateLocalAccount, target set to "ATYMason95810", click "Submit"
  3. Trapped by filter, and got a log
    image.png (835×1 px, 411 KB)
  4. Tried again, trapped again, but no new abuselog record found!
  5. Found another victim user named "AlenaMcclendon9", tried createLocalAccount again
  6. Trapped again, still no abuselog record found! NB: I only received "warning" message from filter rather than "prevention".
    image.png (746×1 px, 100 KB)
TheresNoTime subscribed.May 7 2022, 2:29 AM
TheresNoTime added a comment.May 7 2022, 2:35 AM

Can you test this with a filter action of just disallow without the initial warning action too?

TheresNoTime added a project: Stewards-and-global-tools.May 7 2022, 2:36 AM
Tigerzeng updated the task description. (Show Details)May 7 2022, 2:39 AM
Tigerzeng added a comment.May 7 2022, 2:45 AM
In T307827#7911121, @TheresNoTime wrote:

Can you test this with a filter action of just disallow without the initial warning action too?

Looks like the same (on zhwiki).

Stang added a comment.EditedMay 7 2022, 2:48 AM

Something even more strange happened: I created a new filter and marked the previous filter as "deleted". Note: this new filter detect different sequence in account name. When trying to force create a local account whose name matched the new filter's rule (and did NOT match the old, deleted filter's rule), I was trapped again, and the warning message for the previous, deleted filter was shown to me.

image.png (598×1 px, 71 KB)

DannyS712 subscribed.May 7 2022, 4:23 AM
• Zabe subscribed.May 7 2022, 7:18 AM
Wnme subscribed.Nov 20 2022, 10:04 AM
matej_suchanek mentioned this in T323969: AbuseFilter: Apparent bug with Special:CreateLocalAccount.Nov 29 2022, 7:34 AM
Dragoniez subscribed.Dec 2 2022, 10:26 AM
Dragoniez triaged this task as High priority.Dec 21 2023, 6:16 PM
Dragoniez mentioned this in T307828: Separate Special:CreateLocalAccount from autocreateaccount in abuse filters.Dec 21 2023, 6:20 PM
matej_suchanek mentioned this in T366858: AbuseFilter does not report user_group or user_name when CreateLocalAccount is performed.Jun 22 2024, 3:30 PM
Tgr subscribed.Jun 22 2024, 4:11 PM

Autocreate errors are cached for 5 minutes for performance (since autocreate is attempted on every pageview), so assuming the initial retries are within that time frame, this is working as expected.

Xiplus subscribed.Jul 17 2024, 12:08 AM
Dragoniez closed this task as Resolved.Oct 13 2025, 3:49 PM
Dragoniez assigned this task to XtexChooser.

I tested this on my local MW installation in relation to T366858, and it appears that this was implicitly fixed in rMW50dd99e. Currently, AuthManager::autoCreateUser contains:

		$session = null;
		if ( !$performer || $performer->getUser()->equals( $user ) ) {
			$session = $this->request->getSession();
		}

		// Check the session, if we tried to create this user already there's
		// no point in retrying.
		if ( $session && $session->get( self::AUTOCREATE_BLOCKLIST ) )

$performer is the user who forcibly autocreates a local account (i.e., $user). When someone uses CreateLocalAccount, $performer and $user are different, meaning $session remains null. So the code doesn't get into the if block to use the cache, meaning the forcible autocreation is logged.

Restricted Application added a project: MediaWiki-Platform-Team. · View Herald TranscriptOct 13 2025, 3:49 PM
Dragoniez merged a task: T323969: AbuseFilter: Apparent bug with Special:CreateLocalAccount.Oct 13 2025, 3:54 PM
Dragoniez added a subscriber: matej_suchanek.
Stang unsubscribed.Oct 16 2025, 8:33 PM
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL · Credits