Last modified: 2010-05-15 16:03:42 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"/>
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.
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.
(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.
(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?
(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.