Page MenuHomePhabricator

Autoblocks popping up for long-since blocked users frequently
Closed, ResolvedPublic


From [[WP:VPT]]:

We're seeing autoblocks pop up in cases where the blocked user hasn't edited in a Very Long Time. For instance, at [[User talk:Esoglou]], we see he was hit by an autoblock from an account blocked in late 2009. I've seen several other such today.

and should show (in this case) the autoblock information; I don't see any way to lift an autoblock any more.

Version: 1.18.x
Severity: normal



Event Timeline

bzimport raised the priority of this task from to High.Nov 21 2014, 11:48 PM
bzimport set Reference to bz31403.

BlockList fix made in r99076.

In any case, on my testwiki, clicking the "change block" link lets me undo autoblocks without problems.

Autoblocks are created when User::getBlockedStatus() is called. It's possible that in 1.17, this function was only called when the user attempted to edit, whereas in 1.18, it is called more often, perhaps when the user logs in via CentralAuth to another wiki. If this is the case, then it is a performance regression as well as a nuisance.

I investigated block #3618416. The user in question is permanently blocked on, but was editing at approximately the time of the autoblock.

14:39, 6 October 2011 Autoblock #3620311 14:39, 7 October 2011 (unblock) Jpgordon (talk | contribs | block) account creation blocked (Autoblocked because your IP address was recently used by "Jpotts15". The reason given for Jpotts15's block is: "Vandalism-only account".)

Here's another: -- this time the block was in 2010.

More verification of global cause: an unblock request on enwiki related to

She's blocked on enwiki since 11 May 2010.

Backtrace on usual page view of a special page:
#1 D:\Projects\MediaWiki\includes\User.php(1550): User->getBlockedStatus(true)
#2 D:\Projects\MediaWiki\includes\User.php(1540): User->getBlock(true)
#3 D:\Projects\MediaWiki\includes\Skin.php(639): User->isBlocked()
#4 D:\Projects\MediaWiki\includes\SkinTemplate.php(247): Skin->getUndeleteLink()
#5 D:\Projects\MediaWiki\includes\OutputPage.php(1876): SkinTemplate->outputPage()
#6 D:\Projects\MediaWiki\includes\Wiki.php(381): OutputPage->output()
#7 D:\Projects\MediaWiki\includes\Wiki.php(624): MediaWiki->finalCleanup()
#8 D:\Projects\MediaWiki\includes\Wiki.php(532): MediaWiki->main()
#9 D:\Projects\MediaWiki\index.php(58): MediaWiki->run()
#10 {main}

This whole bloody system of implicit autoblocks needs a rewrite.

Caused by r93246, reverted in r93246.

(In reply to comment #6)

Grrr, reverted in r99211.

That reverted code that was not deployed. The reverted code would have made this worse if it was deployed, though.

Possible fix in r99323 to reduce occurrence of this.

since this hasn't been deployed yet, here is another (similar) report:

(In reply to comment #9)

since this hasn't been deployed yet, here is another (similar) report:

I don't see the relation? Wrong link?

alexsm333 wrote:

Correct link to report:

Comment: it would be nice to at least have a "hint" that IP is rangeblocked like it was before (I understand for autoblocks it was a privacy issue)

ronald wrote:

This user
has had 3 autoblocks in a week - all repeating an autoblock 11 months ago.

Assigning to Tim for review of r99323 and followups. Can assign back to Aaron for backporting and deployment

(In reply to comment #12)

This user
has had 3 autoblocks in a week - all repeating an autoblock 11 months ago.

For the record, this new account was at times editing on the same IP address as the original, indefinitely blocked account - and turns out to be a sock of the original account.

While I realise that you're trying to resolve all bugs, and this may only be one aspect of a larger issue to be an early warning system of a returned indef blocked user, this particular bug characteristic is not a net negative.

Reviewed and tagged for backport.

Assigning to Aaron to finish off and deploy.