Author: mediazilla
Description:
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
• bzimport | |
Nov 10 2004, 12:51 PM |
F1365: User.php | |
Nov 21 2014, 7:03 PM |
F1366: User.php.patch.txt | |
Nov 21 2014, 7:03 PM |
Author: mediazilla
Description:
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
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).
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).
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:
(wikibugs-l@wikipedia.org needs to be added to the CC list when changing
assignment.)
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.
Attached: