Page MenuHomePhabricator

Issuing an anon-only block, then changing anon-only setting causes incorrect block settings to be applied for anon user
Closed, ResolvedPublic

Description

When you issue a block to an IP address with the "anonymous users only" option, then later modify the block and decide to extend it to logged in users as well (i.e.: ticking "Prevent logged-in users from editing from this IP address"), the resulting blocks do not function as expected.

If an user tries to edit from the target IP, it'll be caught by the newly modified block and its settings will be applied. However, if an anonymous user tries to edit from the target IP, it'll be caught by the previous block (the one set to "anonymous users only"), and the settings from that old block will be applied. This is the source of admin confusion and also causes the interface to display incorrect information (see screenshots).

Steps to Reproduce

  1. Via Special:Block, block your own IP address, without preventing logged-in users from editing.
  2. Modify your existing block: tick "Prevent logged-in users from editing" and tick "Prevent this user from editing their own talk page..." and save the block
  3. Log out, and as an anon, attempt to edit your own talk page
  4. DEFECT: Interface displays block notice showing you cannot edit your talk page, but you can successfully perform edits.

Live example of this bug in Wikia's environment:

Also reproduced on fresh install of mediawiki-vagrant running latest version (see screenshots)

Expected Behavior
If a block targets an IP address and the "anonymous users only" setting is modified, the previous version of the block should be deleted and new settings should be applied to both anons and users. Current situation can be confusing for admins and also causes interface to show misinformation.

Screenshots

Képernyőfotó 2017-02-07 - 23.30.24.png (1×2 px, 388 KB)

Képernyőfotó 2017-02-07 - 23.30.31.png (1×2 px, 390 KB)

Képernyőfotó 2017-02-07 - 23.52.10.png (1×2 px, 313 KB)

Event Timeline

TK-999 updated the task description. (Show Details)

It seems when software performs block check via User::isBlocked etc., Block::newLoad tries to find the best matching block based on type, and because of https://github.com/wikimedia/mediawiki/blob/master/includes/Block.php#L332 the first match of Block::TYPE_IP (the older block) will always be preferred for anons.

We could consider removing ipb_anon_only field from the ipb_address unique key defined for the ipblocks table schema, which would result in a collision when user tries to submit block in such a way, and thus force a deletion of the old block.

There might be an use case where we want different block options to apply for blocked anons and blocked users editing from the source IP address. However this behavior is confusing:

  • this is currently not handled properly by the interface - as illustrated by the screenshots, it always displays info for latest block
  • Special:Block will always load the latest block for the IP address, even if you click "change block" next to the block log entry of the first block
  • this behavior is undocumented (see https://www.mediawiki.org/wiki/Help:Blocking_users) - it requires knowledge of DB schema and MW source to know that "anon. only" option causes a separate block to be created, which is probably not something we should assume to be public knowledge
MacFan4000 subscribed.

I was able to reproduce with MW 1.28 and 1.30. It seems to also register as a new block.

Remiving Xauroflaux as a subscriber as their global account is locked for impersonating another user.

MacFan4000 added projects: MW-1.28-release, MW-1.29-release, MW-1.30-release.

@MacFan4000: Could you explain why this issue has become important enough that it should block releasing the next tarballs of MediaWiki 1.28, 1.29 and 1.30?

This is an important issue to be addressed but I wouldn't consider it as a blocker for MediaWiki 1.29.

MacFan4000 claimed this task.

Oh, sorry

MacFan4000 removed MacFan4000 as the assignee of this task.

Oops

T251188 should fix this issue.