Last modified: 2005-10-19 06:55:10 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 856 - Auto-IP blocks last past the original block length
Auto-IP blocks last past the original block length
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Normal major with 6 votes (vote)
: ---
Assigned To: Tony Sidaway
:
: 1888 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-10 12:51 UTC by Anthony
Modified: 2005-10-19 06:55 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Fixed the bug. Check if the auto-block excedes the user-block (46.92 KB, patch)
2005-10-07 12:14 UTC, Ting Chen
Details
Patch for the fix (820 bytes, patch)
2005-10-08 14:26 UTC, Ting Chen
Details

Description Anthony 2004-11-10 12:51:40 UTC
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.
Comment 1 Jeff Bonham 2005-01-09 20:47:12 UTC
Possibly related to bug 1156, bug 1204 
Comment 2 Anthony 2005-01-09 22:23:22 UTC
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).
Comment 3 Brion Vibber 2005-01-29 07:46:20 UTC
Is this a bug or intended behavior?
Comment 4 Jeff Bonham 2005-04-07 23:12:12 UTC
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). 
Comment 5 Piotr Matuszewski 2005-04-19 10:52:07 UTC
*** Bug 1888 has been marked as a duplicate of this bug. ***
Comment 6 Peter Gervai (grin) 2005-06-24 08:03:43 UTC
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.
Comment 7 Mark Ryan 2005-07-04 02:47:13 UTC
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.
Comment 8 Nathan J. Yoder 2005-07-04 05:11:22 UTC
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.
Comment 9 Tony Sidaway 2005-07-22 02:50:40 UTC
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.
Comment 10 Zigger 2005-07-24 02:25:27 UTC
(wikibugs-l@wikipedia.org needs to be added to the CC list when changing
assignment.)
Comment 11 Ting Chen 2005-10-07 12:14:32 UTC
Created attachment 944 [details]
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.
Comment 12 Ting Chen 2005-10-08 14:26:37 UTC
Created attachment 952 [details]
Patch for the fix

cvs patch.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links