View contributions / recentchanges for an IP range
OpenPublic

Assigned To
None
Priority
Lowest
Author
bzimport
Commits
Unknown Object (Commit)
Subscribers
scfc, Legoktm, Matanya and 9 others
Projects
Reference
bz1035
Description

Author: fennec

Description:
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.


Version: unspecified
Severity: enhancement
URL: http://en.wikipedia.org/wiki/Special:Contributions/127.0.0.1

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz1035.
bzimport created this task.Via LegacyDec 8 2004, 12:15 AM
bzimport added a comment.Via ConduitDec 8 2004, 12:18 AM

jeluf wrote:

Would it be sufficient to list the contributions of the last week?
Could reduce the DB load while preparing these reports.

bzimport added a comment.Via ConduitDec 8 2004, 12:22 AM

fennec wrote:

(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...

bzimport added a comment.Via ConduitDec 8 2004, 12:33 AM

shakes wrote:

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?

bzimport added a comment.Via ConduitDec 8 2004, 2:31 PM

zigger wrote:

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

bzimport added a comment.Via ConduitDec 8 2004, 6:02 PM

fennec wrote:

(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".

bzimport added a comment.Via ConduitDec 8 2004, 11:12 PM

shakes wrote:

OK then, I'll implement that. :)

hashar added a comment.Via ConduitDec 8 2004, 11:22 PM

(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

bzimport added a comment.Via ConduitMay 7 2005, 2:19 PM

krubokrubo wrote:

*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.

bzimport added a comment.Via ConduitJun 2 2005, 7:52 PM

magnusrk+wiki wrote:

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.

bzimport added a comment.Via ConduitSep 9 2005, 1:21 PM

zigger wrote:

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

MaxSem added a comment.Via ConduitAug 27 2006, 1:39 PM

Created attachment 2273
Patch that allows to view contribs of IP range

Here's what I can think of. Hope it isn't too time-consuming.

Attached: SpecialContributions.patch

aaron added a comment.Via ConduitFeb 27 2007, 10:18 PM

Done in r20075.

MaxSem added a comment.Via ConduitMay 5 2007, 9:03 AM

Why it was reverted?

bzimport added a comment.Via ConduitMay 5 2007, 9:05 AM

lcarsdata wrote:

It was not.

MaxSem added a comment.Via ConduitMay 5 2007, 9:11 AM

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."

Raymond added a comment.Via ConduitMay 5 2007, 9:15 AM

The relevant revert was r21379 by Brion with comment "remove sssllloowwwwwww
range checks" --> Reopen

MaxSem added a comment.Via ConduitMay 5 2007, 9:31 AM

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?

bzimport added a comment.Via ConduitJun 20 2007, 12:05 PM

robchur wrote:

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

aaron added a comment.Via ConduitJun 23 2007, 2:52 PM

(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.

Raymond added a comment.Via ConduitNov 6 2007, 5:38 PM
  • Bug 11887 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitMay 31 2008, 12:24 AM

Wiki.Melancholie wrote:

Shouldn't that be easy to fix, as this already works with the API of MediaWiki!?
See

bzimport added a comment.Via ConduitJun 1 2008, 3:26 PM

ayg wrote:

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.

Catrope added a comment.Via ConduitJun 1 2008, 8:30 PM

(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.

bzimport added a comment.Via ConduitJun 1 2008, 10:43 PM

ayg wrote:

(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.

bzimport added a comment.Via ConduitDec 28 2008, 10:14 PM

mike.lifeguard+bugs wrote:

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?

bzimport added a comment.Via ConduitDec 28 2008, 10:30 PM

ayg wrote:

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.

bzimport added a comment.Via ConduitDec 28 2008, 10:31 PM

mike.lifeguard+bugs wrote:

(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...

bzimport added a comment.Via ConduitDec 28 2008, 10:35 PM

ayg wrote:

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.

siebrand added a comment.Via ConduitFeb 2 2009, 12:39 PM

Changed component to "RecentChanges"

bzimport added a comment.Via ConduitJan 26 2010, 10:11 PM

jasonspiro4 wrote:

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.

Peachey88 added a comment.Via ConduitApr 30 2011, 12:09 AM

*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*

bzimport added a comment.Via ConduitAug 24 2011, 3:25 PM

john wrote:

+reviewed

Was applied in core and revert later due to slowness

Martijn_Hoekstra added a comment.Via ConduitFeb 23 2012, 12:06 AM

I've got a userscript which does something similar. It could be of help: https://en.wikipedia.org/wiki/User:Martijn_Hoekstra/checkrange.js

Matanya added a comment.Via ConduitJul 26 2012, 11:48 AM

Now we need to support IPv6 as well, if this is ever going to be implemented.

OdMishehu added a comment.Via ConduitNov 11 2012, 8:30 AM

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.

Qgil added a comment.Via ConduitMay 17 2014, 12:51 AM

Does this feature need to be solved by MediaWiki Core, or can this very specific use case be provided by a specific web tool?

Legoktm added a comment.Via ConduitMay 17 2014, 12:55 AM

(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.

Diffusion added a commit: Unknown Object (Commit).Via DaemonsWed, Mar 4, 8:20 AM
Qgil added a comment.Via WebWed, Mar 4, 8:40 AM

Accidental clash. Known issue. Sorry for the noise.

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.