Page MenuHomePhabricator

Expose own IP address in API
Open, Needs TriagePublic

Description

Currently, there doesn’t seem to be a way to discover the current user’s IP address through the API if they’re logged in. However, sometimes this is useful information.

Example:
When using the intestactions feature of action=query&prop=info (test if the user is allowed to perform a certain action), it’s possible that the user will get a permission error because they’re using an IP address that has been blocked, including for logged-in users (e. g. a VPN). But the response doesn’t include the affected IP, so the app/script/etc. using the API has no way to present the user with a message like MediaWiki:blockedtext:

… Your current IP address is $3, and the block ID is #$5.
Please include all above details in any queries you make.

It’s possible to make a separate request for the block with that number, of course, but that will only yield the entire IP range, not the IP of the user being affected.

Proposal:
Add an ip prop to the action=query&meta=userinfo module.

Open questions:
Are there any privacy concerns with letting users query their own IP address? (There are plenty of other websites that offer this feature, of course, but perhaps there are some scenarios where it still matters?)

Event Timeline

Restricted Application added a project: Platform Engineering. · View Herald TranscriptDec 12 2019, 12:56 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Lucas_Werkmeister_WMDE renamed this task from Expose IP address in API to Expose own IP address in API.Dec 12 2019, 2:00 PM
Michael claimed this task.Dec 12 2019, 2:06 PM
Restricted Application added a project: User-Michael. · View Herald TranscriptDec 12 2019, 2:06 PM

Change 556683 had a related patch set uploaded (by Michael Große; owner: Michael Große):
[mediawiki/core@master] Expose own IP address in API

https://gerrit.wikimedia.org/r/556683

Anomie moved this task from Unsorted to Needs details or plan on the MediaWiki-API board.EditedDec 12 2019, 2:40 PM
Anomie added a subscriber: Anomie.

I note you could do this by forcing a logged-out response, as that reports the IP as the username. There are a few ways to do that. Given that, adding the client IP specifically to meta=userinfo doesn't seem like much of a problem.

On the other hand, that the above works has been reported as a bug ({T70544}) and if T227733: Draft: Masking IP addresses for increased privacy ever happens it would likely break the above methods, so there should probably be an actual resolution of the explicit question as to whether we want this feature available.

To me this seems a bit like the wrong approach. Shouldnt the you are blocked api response comtain all the relavent info about the block, including ip if that is relavent. It seems a bit fragile to require the client to know that for this type of block, users ip is relavent info.

When doing the real action it shows the same result. I may looks a bit better when using errorformat=html, but for intestactions there is no way to define a format

In both cases it is the apierror-blocked message, not the blockedtext message from the task description

It seems a bit fragile to require the client to know that for this type of block, users ip is relavent info.

MediaWiki core shows the IP address for all kinds of blocks, regardless of whether it’s relevant or not; we would do the same.

but for intestactions there is no way to define a format

There is – it obeys the overall errorformat. (But if the errorformat is the default bc, then it says “eew” and uses plaintext instead.)

However –

In both cases it is the apierror-blocked message, not the blockedtext message from the task description

– the API maps “blocked” errors to a different structure, for example the original error

{
    "code": "blocked",
    "key": "blockedtext",
    "params": [
        "[[User:Lucas Werkmeister|‪Lucas Werkmeister‬]]",
        "also block IP address",
        "127.0.0.1",
        "‪Lucas Werkmeister‬",
        5,
        "infinite",
        "‪Eternally blocked user‬",
        "18:09, 5 December 2018"
    ]
}

gets turned into

{
    "code": "blocked",
    "key": "apierror-blocked",
    "params": [],
    "data": {
        "blockinfo": {
            "blockid": 5,
            "blockedby": "Lucas Werkmeister",
            "blockedbyid": 1,
            "blockreason": "also block IP address",
            "blockedtimestamp": "2018-12-05T17:09:57Z",
            "blockexpiry": "infinite"
        }
    }
}

which has the side effect of discarding the IP address, since not all of the original message parameters make it into the blockinfo. If it didn’t do this (and no other kind of error receives such special treatment, as far as I can see), then we would already have all the information we need.

which has the side effect of discarding the IP address, since not all of the original message parameters make it into the blockinfo.

I note that the IP address isn't really info about the block.

I also note it was added to the message back in 2003. These days the block ID seems likely to be more generally useful than the IP.

and no other kind of error receives such special treatment, as far as I can see

There are a number of other errors that get transformed for historical reasons, but you're right that no others have structured data added.

Ideally the structured data would be added when the message gets created, but tracking down and updating all the creators of "blocked" messages seemed a daunting task. Plus the only way to add structured data to a message is currently kind of hacky; it'll likely be better once we switch to MessageValue.

JFishback_WMF moved this task from Intake to Backlog on the Privacy board.Feb 4 2020, 11:21 PM
Addshore removed a subscriber: Addshore.Apr 6 2020, 10:59 AM