Last modified: 2011-05-15 10:06:41 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T10218, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 8218 - Make finding rangeblocks affecting a given IP easier
Make finding rangeblocks affecting a given IP easier
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
User blocking (Other open bugs)
unspecified
All All
: Normal enhancement with 8 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-11 15:33 UTC by Ronald Beelaard
Modified: 2011-05-15 10:06 UTC (History)
4 users (show)

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


Attachments

Description Ronald Beelaard 2006-12-11 15:33:33 UTC
When an IP range has been blocked for whatever reason, it is virtually 
impossible to find the status of an individual IP within that range.
The ipblocklist includes the data of the block, however starting from an 
individual IP, it is a bit gambling to find the right lower range boundary 
and if so, it is still difficult to find the range parm. In particular if 
the ipblocklist consists of many pages.

A SQL query to resolve this (e.g. with an INNER JOIN xxx BETWEEN yy1 AND 
yy2 construct), is quite expensive as far as cpu resources is concerned 
(at least in a Microsoft environment). A solution could be a simple 
additional table with 2 fields (range and each individual ip within that 
range) which is UNION'ed to the already existing block table (I presume).

The issue has been triggered by an extensive project on nl:w to fight 
trolls/sockpuppets working via open proxies. Recently one of those 
appeared to use dynamic IP's for mobile internetting.
Comment 1 Ronald Beelaard 2006-12-12 02:27:09 UTC
A related flaw, just discovered.
An IP range n1.n2.n3.n4/24 was blocked. Due to a bug in the bot, unblocking was 
done on the base only n1.n2.n3.n4. The unblocking was successful.

However, querying the ipblocklist on n1.n2.n3.n4/24 returns that the range is 
still blocked. The unblock log gives a successful unblock for the base address.

Example to be found on nl.wikipedia 87.79.3.0/24. I'll leave the inconsistent 
state for a few days.
 
Comment 2 Aaron Schulz 2007-08-23 22:25:03 UTC
Note that, although it is nasty hackish use for this, CheckUser will list out blocks for users/IPs, included range blocks and autoblocks, linking to the log/ipblocklist respectively (autoblocks are not logged).
Comment 3 Mike.lifeguard 2009-03-16 00:00:54 UTC
There is a tool which searches for blocks on all wikis, and will return rangeblocks which affect the given IP. On integrating this into core software, perhaps someone can see if the performance concerns mentioned in comment 0 are still correct?

I've changed the summary, since the old one was a bit hard to parse quickly for me.

(In reply to comment #1)
> A related flaw, just discovered.
> An IP range n1.n2.n3.n4/24 was blocked. Due to a bug in the bot, unblocking was 
> done on the base only n1.n2.n3.n4. The unblocking was successful.
> 
> However, querying the ipblocklist on n1.n2.n3.n4/24 returns that the range is 
> still blocked. The unblock log gives a successful unblock for the base address.
> 
> Example to be found on nl.wikipedia 87.79.3.0/24. I'll leave the inconsistent 
> state for a few days.
>  

If you can still replicate this, it'd be a separate bug.
Comment 4 Happy-melon 2011-03-23 20:39:59 UTC
As of at least r84534, this is fixed: Going to Special:BlockList/1.2.3.4 shows blocks on the IP 1.2.3.4, and all rangeblocks containing it.

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


Navigation
Links