Last modified: 2010-05-15 16:03:42 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 T16405, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 14405 - API block query no longer accepts CIDR
API block query no longer accepts CIDR
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
1.13.x
All All
: Normal major (vote)
: ---
Assigned To: Roan Kattouw
http://en.wikipedia.org/w/api.php?act...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-04 14:36 UTC by Chris Howie
Modified: 2010-05-15 16:03 UTC (History)
2 users (show)

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


Attachments

Description Chris Howie 2008-06-04 14:36:56 UTC
The action=query&list=blocks API call used to accept bkusers with / in them for range blocks.  Now they are rejected with:

<error code="bkparam_user" info="User name 162.84.178.166/31 is not valid"/>
Comment 1 Roan Kattouw 2008-06-19 14:09:29 UTC
CIDR ranges were accepted in the past but never worked properly: bkusers=162.84.178.166/31 would only fetch a block that blocks exactly that range. With the introduction of the bkip parameter in r36452, you can now specify CIDR ranges, although the functionality is limited: you can only fetch blocks that affect an entire range, but you can't fetch blocks that affect only part of a range (for performance reasons). The most practical use case of bkip is probably to supply a single IP, which will list all blocks applying to that IP, but it's possible to check for range blocks this way too, and since list=blocks now accepts CIDR ranges, the bug as reported has been fixed.
Comment 2 Chris Howie 2008-06-19 14:13:12 UTC
Actually, the behavior you describe as not working properly is the one that I used.  :)

To check for a range block against an IP I would generate the CIDR notation for each subnet up to /16 and pass all of those to the API glued with "|".  Which worked until "/" broke.

Anyway, thanks for the fix.  Looking forward to seeing it hit en.wp.
Comment 3 Roan Kattouw 2008-06-19 14:19:41 UTC
(In reply to comment #2)
> Actually, the behavior you describe as not working properly is the one that I
> used.  :)
> 
> To check for a range block against an IP I would generate the CIDR notation for
> each subnet up to /16 and pass all of those to the API glued with "|".  Which
> worked until "/" broke.

Good thing that checking for range blocks is now supported properly, then. You can now just do bkip=162.84.178.166 and you'll get all (range) blocks applying to that IP.

Comment 4 Chris Howie 2008-06-19 14:25:05 UTC
(In reply to comment #3)
> Good thing that checking for range blocks is now supported properly, then. You
> can now just do bkip=162.84.178.166 and you'll get all (range) blocks applying
> to that IP.

Indeed, this is good news.  Will the results also include blocks against the IP itself (non-range) as well as autoblocks?
Comment 5 Roan Kattouw 2008-06-19 14:29:59 UTC
(In reply to comment #4)
> Indeed, this is good news.  Will the results also include blocks against the IP
> itself (non-range) as well as autoblocks?
> 

Yes. In general, bkip=nnn.nnn.nnn.nnn/N will return all blocks blocking exactly that range, or a broader range (i.e. with a smaller N) that bkip is part of. Specifying a single IP is equivalent to N=32, so it'll grab all blocks blocking the IP itself or a range that contains it.

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


Navigation
Links