Page MenuHomePhabricator

Ensure that anywhere BlockDisablesLogin is used, it does not affect partial blocks
Open, Needs TriagePublic

Description

Problem
The config setting BlockDisablesLogin is used to use blocking to prevent users from logging in. If this config setting is set to true:

$wgBlockDisablesLogin = true;

then the user inherits the same permissions as anon until they log out. After they log out, they are unable to login (even if they are only partially blocked).

Event Timeline

dbarratt created this task.Nov 6 2018, 8:52 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptNov 6 2018, 8:52 PM
Restricted Application added a subscriber: MGChecker. · View Herald TranscriptNov 6 2018, 8:52 PM
TBolliger triaged this task as Lowest priority.Nov 6 2018, 8:59 PM
TBolliger moved this task from Untriaged to Backlog on the Anti-Harassment board.
TBolliger added a subscriber: TBolliger.

Correct me if I'm wrong, but Wikimedia wikis do not use this functionality.

Correct me if I'm wrong, but Wikimedia wikis do not use this functionality.

There are a few that do:
https://phabricator.wikimedia.org/source/mediawiki-config/browse/master/wmf-config/InitialiseSettings.php$8286

It was enabled in T55871 and T74589

Still low priority. I assume it'll be an easy fix., but no rush.

dmaza added a subscriber: dmaza.Nov 6 2018, 9:39 PM

This is arguably working as intended. I would agree this is low priority.

This is arguably working as intended. I would agree this is low priority.

If you have the config enable, then creating a partial block on someone would cause them to not be able to log in, which sounds extreme when your only intention is to block them from editing a single page.

dmaza added a comment.Nov 8 2018, 4:28 AM

This is arguably working as intended. I would agree this is low priority.

If you have the config enable, then creating a partial block on someone would cause them to not be able to log in, which sounds extreme when your only intention is to block them from editing a single page.

I agree it might be extreme but the flag doesn't specify anything different so technically it is not broken

Dinoguy1000 renamed this task from Ensure that anywhere BlockDisablesLogin is used, it does not effect partial blocks to Ensure that anywhere BlockDisablesLogin is used, it does not affect partial blocks.Nov 8 2018, 8:58 AM
aezell added a subscriber: aezell.Nov 8 2018, 6:53 PM

It seems to fall into the same class as our other discussion about isBlocked and sitewide. We've changed the whole paradigm so we have to have a more holistic view of what the desired outcomes are and not just what this small block of code does.

I think the priority is low here and that we should seek some other input from those communities that use this config setting.

Yes, Lowest priority. I think we can probably walk away from this project and not touch this ticket at all.

TBolliger closed this task as Declined.Jan 30 2019, 10:45 PM
dbarratt reopened this task as Open.Mar 6 2019, 3:47 PM
dbarratt removed a project: Anti-Harassment.

FYI: This is a problem with any "restricted" wiki on the sitematrix:
https://meta.wikimedia.org/wiki/Special:SiteMatrix#mw-sitematrix-others

Since this is still an issue with MediaWiki itself, I'm going to keep this issue open and remove Anti-Harassment

dbarratt updated the task description. (Show Details)Mar 6 2019, 3:48 PM
dbarratt raised the priority of this task from Lowest to Needs Triage.Mar 6 2019, 4:03 PM

BlockDisablesLogin is used on private and fishbowl wikis (otrswiki, officewiki, …). They grant no rights to anons (except for fishbowls chapter wikis and foundationwiki, which do allow reading). In particular, they disallow signup. Blocks are meant to approximate account removal there. For example, after the term for a role like CheckUser or Steward expires, or after a chapter member leaves.

I presume that a partial block used by admins on such wiki today, would not apply a partial block but instead block the user site-wide and revoke their ability to login. Assuming partial blocks will be enabled by default eventually, this represents technical debt, and arguably a regression. It seems easy to mitigate without major changes, though:

  1. We could toggle the partial block feature off if BlockDisablesLogin is in use. This is the simplest option. No special support, keeps it like it is today.
  2. We could inform admins through the Special:Block interface (if BlockDisablesLogin is on), that attempting to use partial blocks will also block the target sitewide, and revoke their ability to log in. This would documents today's accidental state.
  3. We could update BlockDisablesLogin code to check Block->isSitewide instead of getBlock. As @aezell mentioned, this is similar to what we've done past months with other features that could previously assume a block to be site-wide.
  1. We could update BlockDisablesLogin code to check Block->isSitewide instead of getBlock. As @aezell mentioned, this is similar to what we've done past months with other features that could previously assume a block to be site-wide.

I think this is the best option, however, we need to figure out a way to message to the user of Special:Block what is happening. Perhaps there is pseudo option represented as a checkbox at the top of the form that is "Prevent Login" that disables the "Editing" section (and all other options for that matter). If the user unchecks the checkbox, the user is forced into an Editing block that is partial (the "Sitewide" option would be disabled).

Does that make sense?

This would be similar to the solution for T219931.

@dbarratt @Krinkle I notice that if $wgBlockDisablesLogin = true and the user's IP is blocked (but not the username) they are prevented from sending emails, even if the IP block does not apply to emails.

I think the issue is around https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/master/includes/user/User.php#3426. This removes rights from a user if they have any blocks, including IP/range blocks. But, I think $wgBlockDisablesLogin is only supposed to apply to username blocks.

Should this be dealt with here, or raise a separate ticket?

@dbarratt @Krinkle I notice that if $wgBlockDisablesLogin = true and the user's IP is blocked (but not the username) they are prevented from sending emails, even if the IP block does not apply to emails.
I think the issue is around https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/master/includes/user/User.php#3426. This removes rights from a user if they have any blocks, including IP/range blocks. But, I think $wgBlockDisablesLogin is only supposed to apply to username blocks.
Should this be dealt with here, or raise a separate ticket?

Uhh... a separate ticket please. :)