Last modified: 2014-10-08 08:20:21 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 1035 - View contributions / recentchanges for an IP range
View contributions / recentchanges for an IP range
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
unspecified
All All
: Lowest enhancement with 12 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/wiki/Special:...
: patch, patch-reviewed, schema-change
: 3404 10320 11887 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-08 00:15 UTC by Fenenc Foxen
Modified: 2014-10-08 08:20 UTC (History)
21 users (show)

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


Attachments
Patch that allows to view contribs of IP range (1.43 KB, patch)
2006-08-27 13:39 UTC, Max Semenik
Details

Description Fenenc Foxen 2004-12-08 00:15:10 UTC
There should be a method of viewing contributions for all anonymous users within
a certain range of IP addresses, or at the very least a list of IPs in a certain
range which have contributed. This would be quite useful at tracking down
malicious contributions from users who have a dynamic IP within a certain range.

Optionally, this feature could be restricted to certain users (on Wikipedia,
perhaps sysops) in the interest of privacy and database performance.
Comment 1 JeLuF 2004-12-08 00:18:34 UTC
Would it be sufficient to list the contributions of the last week?
Could reduce the DB load while preparing these reports.
Comment 2 Fenenc Foxen 2004-12-08 00:22:49 UTC
(In reply to comment #0)
> There should be a method of viewing contributions for all anonymous users within
> a certain range of IP addresses, or at the very least a list of IPs in a certain
> range which have contributed. This would be quite useful at tracking down
> malicious contributions from users who have a dynamic IP within a certain range.
> 
> Optionally, this feature could be restricted to certain users (on Wikipedia,
> perhaps sysops) in the interest of privacy and database performance.

(In reply to comment #1)
> Would it be sufficient to list the contributions of the last week?
I don't know... sometimes you might find some vandalism which is older than a week,
and a simple way to check whether or not there are any similar contributions lurking
about. It'd be better than nothing, mind you, but...
Comment 3 Shane King 2004-12-08 00:33:31 UTC
The problem I see is that IP addresses are stored as x.x.x.x strings against
contributions. That doesn't make it easy to write a query that's going to
perform well for a range search, unless you limit it to be able to search:

x.*.*.*
x.y.*.*
x.y.z.*

and nothing finer grained. Would that be sufficient perhaps?
Comment 4 Zigger 2004-12-08 14:31:30 UTC
This enhancement was also requested by Guanaco in July 2004 at
http://sourceforge.net/tracker/index.php?func=detail&aid=994989&group_id=34373&atid=411195
Comment 5 Fenenc Foxen 2004-12-08 18:02:18 UTC
(In reply to comment #3)
> x.y.*.*
> x.y.z.*
> and nothing finer grained. Would that be sufficient perhaps?

Actually, I think that would be quite effective with most inquiries, and much
better than "nothing".
Comment 6 Shane King 2004-12-08 23:12:54 UTC
OK then, I'll implement that. :)
Comment 7 Antoine "hashar" Musso (WMF) 2004-12-08 23:22:24 UTC
(In reply to comment #6)
> OK then, I'll implement that. :)

While you are at it, don't forget the following examples:

192.168.0.0/16

You can get some c code using netmask sources:
http://ftp.scarlet.be/pub/debian/pool/main/n/netmask/netmask_2.3.7.tar.gz
(c) Robert Stone <talby(at)debian(dot)org> GPL
Comment 8 Paul Dexter 2005-05-07 14:19:41 UTC
*ping*   I'm voting for any form of this you can write.

x.y.*.* for the last week would be very helpful in spotting vandalism.
Comment 9 Dashiva 2005-06-02 19:52:27 UTC
This isn't just an enhancement. When you ban an IP range with the block user page and a range like 12.64.96.0/24, the confirmation page 
includes a link to the contributions of said user. This obviously leads to nothing, since there have been no contributions from that 
literal user or IP. I suppose this could be changed to not give a link, but I would much rather see a.b.c.d/x giving results for the 
appropriate IPs.
Comment 10 Zigger 2005-09-09 13:21:33 UTC
*** Bug 3404 has been marked as a duplicate of this bug. ***
Comment 11 Max Semenik 2006-08-27 13:39:06 UTC
Created attachment 2273 [details]
Patch that allows to view contribs of IP range

Here's what I can think of. Hope it isn't too time-consuming.
Comment 12 Aaron Schulz 2007-02-27 22:18:28 UTC
Done in r20075.
Comment 13 Max Semenik 2007-05-05 09:03:10 UTC
Why it was reverted?
Comment 14 Robert Leverington 2007-05-05 09:05:03 UTC
It was not.
Comment 15 Max Semenik 2007-05-05 09:11:11 UTC
It was: http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/
SpecialContributions.php?r1=20104&r2=20143

by Tim with commnet "Revert r20075, causes SQL error."
Comment 16 Raimond Spekking 2007-05-05 09:15:06 UTC
The relevant revert was r21379 by Brion with comment "remove sssllloowwwwwww
range checks" --> Reopen
Comment 17 Max Semenik 2007-05-05 09:31:16 UTC
Maybe, it should be possible to enable this feature in LocalSettings.php? And 
disable it by default on Wikimedia wikis, until someone invents a way to make it 
faster?
Comment 18 Rob Church 2007-06-20 12:05:12 UTC
*** Bug 10320 has been marked as a duplicate of this bug. ***
Comment 19 Aaron Schulz 2007-06-23 14:52:51 UTC
(In reply to comment #17)
> Maybe, it should be possible to enable this feature in LocalSettings.php? And 
> disable it by default on Wikimedia wikis, until someone invents a way to make it 
> faster?

Such as if an IP hex was stored, which would allow for any CIDR too.
Comment 20 Raimond Spekking 2007-11-06 17:38:11 UTC
*** Bug 11887 has been marked as a duplicate of this bug. ***
Comment 21 Melancholie 2008-05-31 00:24:24 UTC
Shouldn't that be easy to fix, as this already works with the API of MediaWiki!?
See
* http://en.wikipedia.org/w/api.php ("list=usercontribs")
* http://de.wikipedia.org/w/api.php?action=query&list=usercontribs&uclimit=50&ucuserprefix=217.123.
Comment 22 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-06-01 15:26:54 UTC
Well, it's mainly a question of writing an interface for it, yes.  Notice, though, that it can't be sorted sensibly (i.e., by date), by either the API or the usual interface, without some rethinking of how things are stored/indexed.
Comment 23 Roan Kattouw 2008-06-01 20:30:06 UTC
(In reply to comment #22)
> Well, it's mainly a question of writing an interface for it, yes.  Notice,
> though, that it can't be sorted sensibly (i.e., by date), by either the API or
> the usual interface, without some rethinking of how things are stored/indexed.
> 

A simple index ain't gonna solve this: we need the index to have user_text first so we can use the LIKE, but timestamp has to come first if we wanna sort by date. With the current schema, it's simply impossible because we can't create an index with two fields first :D

A proper solution would probably involve putting the binary form of the IP address in a separate field.
Comment 24 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-06-01 22:43:42 UTC
(In reply to comment #23)
> A simple index ain't gonna solve this: we need the index to have user_text
> first so we can use the LIKE, but timestamp has to come first if we wanna sort
> by date. With the current schema, it's simply impossible because we can't
> create an index with two fields first :D

As I think I recall explaining to you, yes.

> A proper solution would probably involve putting the binary form of the IP
> address in a separate field.

There's no real proper solution, but a reasonably *fast* solution would probably involve having a table of (ip_range, timestamp, rev_id), with primary index (ip_range, timestamp).  ip_range might actually represent two columns, say some number n with the IP address of the revision with the last n bits (or last n octets) masked off.  Thus an edit by 123.45.67.89 to a page might insert a few rows into this table, like (1, '123.45.67.0', timestamp, rev_id) *and* (2, '123.45.0.0', timestamp, rev_id) *and (3, '123.0.0.0', timestamp, rev_id).  Then a range search that falls along octet boundaries would be simple, and one that doesn't could be either prohibited outright or shoehorned in by doing a bunch of narrow searches and merging, or a broad search and filtering.

PostgreSQL has somewhat better tools to handle this.  It at least wouldn't require the creation of another table, the indexes could be added to the revision table.  But it's still three more indexes, which is kind of unreasonable for a not-horribly-important feature.
Comment 25 Mike.lifeguard 2008-12-28 22:14:26 UTC
Splarka has written some js to get range (and wildcard) contribs from the API - performance doesn't seem to be an issue for that. Is there some reason the same can't be implemented in core PHP?
Comment 26 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-12-28 22:30:46 UTC
I'm guessing that's not sorted in a sensible fashion.  I.e., it's presumably sorted by the IP address, not by date.  If it's sorted by date, it's probably querying a heck of a lot of rows.  Just because something performs well enough for a JS hack to not be so horrible that the sysadmins track it down and delete it because it's causing things to explode, doesn't mean it performs well enough to be put in the core software.
Comment 27 Mike.lifeguard 2008-12-28 22:31:40 UTC
(In reply to comment #26)
> I'm guessing that's not sorted in a sensible fashion.  I.e., it's presumably
> sorted by the IP address, not by date.  If it's sorted by date, it's probably
> querying a heck of a lot of rows.  Just because something performs well enough
> for a JS hack to not be so horrible that the sysadmins track it down and delete
> it because it's causing things to explode, doesn't mean it performs well enough
> to be put in the core software.
> 

IIRC, it's by IP, yes. Not sure how big an issue that is...
Comment 28 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-12-28 22:35:26 UTC
If that would be acceptable, then sure, that could be added to the human interface.  Something similar is already available in the API.

http://en.wikipedia.org/w/api.php?action=query&list=usercontribs&uclimit=50&ucuserprefix=217.123

That doesn't allow CIDR ranges, but you could filter it reasonably cheaply in most cases (I assume that Splarka's tool does that), so it would be acceptable to add.
Comment 29 Siebrand Mazeland 2009-02-02 12:39:24 UTC
Changed component to "RecentChanges"
Comment 30 Jason Spiro 2010-01-26 22:11:33 UTC
FYI, a tool at http://toolserver.org/~soxred93/rangecontribs/ already lets anyone search for contributions made by an arbitrary IP range or list of IPs.  It's probably not obvious to all editors how to use it though:  you must understand CIDR notation in order to use it.
Comment 31 p858snake 2011-04-30 00:09:34 UTC
*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*
Comment 32 John Du Hart 2011-08-24 15:25:48 UTC
+reviewed

Was applied in core and revert later due to slowness
Comment 33 Martijn Hoekstra 2012-02-23 00:06:16 UTC
I've got a userscript which does something similar. It could be of help: https://en.wikipedia.org/wiki/User:Martijn_Hoekstra/checkrange.js
Comment 34 matanya 2012-07-26 11:48:06 UTC
Now we need to support IPv6 as well, if this is ever going to be implemented.
Comment 35 od_mishehu 2012-11-11 08:30:09 UTC
We need this to work with the following features:
1)  It must show autherized users all links the Special:Contributions shows - including links to RevDel-ed edits, for example
2) It must be available for Special:DeletedContributions - again, only for users autherized to see this page.
3) It must be chronological in order, not sorted by IP address
4) I think we do ned this for arbitrary blockable ranges, not just /16 and /24.

The first 2 features are impossible in a toolserver page (although http://toolserver.org/~soxred93/rangecontribs/ is inactive now anyway); and the latter are not supported by the old fix.
Comment 36 Quim Gil 2014-05-17 00:51:32 UTC
Does this feature need to be solved by MediaWiki Core, or can this very specific use case be provided by a specific web tool?
Comment 37 Kunal Mehta (Legoktm) 2014-05-17 00:55:41 UTC
(In reply to Quim Gil from comment #36)
> Does this feature need to be solved by MediaWiki Core, or can this very
> specific use case be provided by a specific web tool?

It should be supported by core.

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


Navigation
Links