Page MenuHomePhabricator

Autoblocks apply regardless of ipblock-exempt right
Open, Needs TriagePublic

Description

Sysops are automatically granted the ipblock-exempt right. As such, they shouldn't be affected by IP blocks, but that turns out to be false.

Steps to reproduce:

  1. Block an account indefinitely with autoblock enabled
  2. Sign in with that account and then logout
  3. Go back to your account with sysop access

You'll find yourself autoblocked and unable to take any action due to the removal of the unblock-self right.

Event Timeline

Sakretsu created this task.Fri, Sep 20, 5:21 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFri, Sep 20, 5:21 PM

Thanks for reporting - this appears to be happening because of cookie blocks rather than autoblocks. Following the steps locally, I find:

  • the sysop is only blocked if cookie blocks are enabled ($wgCookieSetOnAutoblock = true)
  • the sysop sees the same block message as the blocked user, rather than the autoblock message
  • the block ID cookie is set

Note that to confirm this, you'll need to make sure the cookie is cleared first, e.g. by setting the config to false, unblocking the blocked user, and opening the editor as the newly-unblocked user. After that, following the steps in the task description, the sysop should not be blocked (and there should still be an autoblock for anonymous users).

Cookie blocks that spawn from user account blocks are intended to block other logged in users (T5233), and there is currently no 'cookieblock-exempt' right. Perhaps there should be - or perhaps the 'ipblock-exempt' right should protect from cookie blocks too?

It may be that this issue has only been noticed recently because the default config for cookie blocks have recently changed: T191922. I notice that in T191922#4122153 @Krinkle suggested leaving the default in DefaultSettings as false and overriding CommonSettings to true for all WMF wikis. Worth revisiting that idea since cookie blocks can be quite aggressive?

To summarize, this is not strictly speaking a bug, but it may be worth considering:

  • should 'ipblock-exempt' exempt users from cookie blocks too (or should we have a 'cookieblock-exempt' right)?
  • should $wgCookieSetOnAutoblock (and $wgCookieSetOnIpBlock) be false by default in core?

@dmaza - do you have any thoughts on changing the config back to false in core?

dmaza added a comment.Mon, Sep 23, 8:19 PM

@dmaza - do you have any thoughts on changing the config back to false in core?

I believe my argument for that patch was that cookie blocking should be a standard feature and thus be enabled by default in core. We were already enabling it for all our wikis via CommonSettings.

should 'ipblock-exempt' exempt users from cookie blocks too

I think this make sense. Cookie blocks only represent ip targets and if you are ipblock-exempt you should not be affected by it(?).

I believe my argument for that patch was that cookie blocking should be a standard feature and thus be enabled by default in core.

Thanks, I saw your comment on the original task but thought it might be worth revisiting the decision given the confusion that arose here...

Cookie blocks only represent ip targets

Cookie blocks can arise from blocks against IPs or against user accounts. If a cookie block comes from a user account block, it will block logged-in users. That's what's happening to cause this issue.