Page MenuHomePhabricator

Auto-IP blocks last past the original block length
Closed, ResolvedPublic

Assigned To
Authored By
Nov 10 2004, 12:51 PM
Referenced Files
F1365: User.php
Nov 21 2014, 7:03 PM
F1366: User.php.patch.txt
Nov 21 2014, 7:03 PM


Author: mediazilla

For example, if User:trollinator is blocked for 24 hours at 1005 Sunday and
clicks on a broken link at 0955 Monday, the IP address she is using is blocked
until 0955 Tuesday.

Version: unspecified
Severity: major



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 7:03 PM
bzimport set Reference to bz856.

silsor wrote:

Possibly related to bug 1156, bug 1204

mediazilla wrote:

It should be noted that this bug was there from the very beginning. It is a
known design flaw (I believe bug 1204, at least, is new).

Is this a bug or intended behavior?

silsor wrote:

This is a bug. People are regularly blocked for longer than originally intended because of
this bug. I get emails about it all the time.

A better behaviour would be to autoblock the IP for a length of time that would expire at the
same time as the original block, but with a maximum (such as 24 hours).

gonia wrote:

*** Bug 1888 has been marked as a duplicate of this bug. ***

I would have raised this as critical prio. Smaller wikipedias don't have admins
online 24/7 and longer-than-required blocks may raise significant noise.

ultrablue wrote:

The effect of this bug is to reset a user's block from the start whenever they click "edit
this page". However, as I understand it, users do not find out *by software* that they are
blocked until they actually go to this edit page. As a result, their block does not always
technically start until they actually try to edit. And if they go back to an edit page to re-
read their block information (such as to get the name of the blocking administrator) the
block starts again on their current IP address. As far as I know, this is not the intended
effect of blocks.

njyoder wrote:

I should add that this happens even when you're logged in under the username
that was originally blocked (logged in as User:trollinator). I'm not sure if
this should require a different report or not, but it would be helpful to
display a 'view source' that displays the source since they can't edit at the
time (same as when a page as protected). Yes, you can get an xml dump of the
page, from from a UI standpoint it makes more sense to have this option which
the users are used to.

minorityreport wrote:

I've encountered this behavior in the past but have only gotten a real grasp on
what is happening since I've examined the source code.

The problem is in User::spreadBlock() which is executed when
User::GetBlockedStatus() for a logged-in user determines that a user block is in
progress. The function User::spreadBlock() then looks to see if the IP address
is already blocked. If so, it calls Block::updateTimestamp(), which calls
Block::getAutoblockExpiry() to calculate the new expiry time. After checking
that the IP block was an autoblock, this simply adds the global constant
$wgAutoblockExpiry to the timestamp. The default value of this constant is
86400, which programmers will recognise as the number of seconds in a day.

By contrast, if the IP address was not already blocked, the autoblock expiry
time is only set to time+86400 if this is earlier than the user block expiry
time. This code should also be executed in Block::updateTimestamp(). I'm
fixing this in my test wiki now.

zigger wrote:

( needs to be added to the CC list when changing

wing.philopp wrote:

Fixed the bug. Check if the auto-block excedes the user-block

If auto-block excedes the user-block, then the auto-block would not be
prolonged for another 24 hours.


wing.philopp wrote:

Patch for the fix

cvs patch.