Page MenuHomePhabricator

client_ip attribute reports only 127.0.0.1 in PHP/API context
Open, Unbreak Now!PublicBUG REPORT

Description

Description

The WikiLambda extension (a component of Wikifunctions) is using the Metrics Platform PHP library to track the usage of our wikilambda_function_call (private) API endpoint. We include

allOf: 
  $ref: /fragment/http/client_ip/1.0.0#

in the schema so we can get a rough-granularity breakdown of geolocations from which the API is being called. The http.client_ip attribute always gets assigned the value 127.0.0.1.

This is also true of our wikifunctions_run (public) API endpoint.

Notes: each of the endpoint pages linked above includes clickable example calls to the API. This patch declared the stream configuration for the metrics events. Currently there are several thousand events in the corresponding Data Lake table, and every one has 127.0.0.1 for http.client_ip. All other attributes have appropriate values.

Desired behavior/Acceptance criteria

  • The client_ip attribute should be assigned a value that appropriately indicates the address of the system from which the API has been called.

Event Timeline

This sounds like either it's a bug in the Metrics Platform code, or this is us mis-reading what this attribute is meant to convey?

We ran into this three years ago when two of the Growth team's schemas were migrated to Event Platform. Might be useful to check what was done there: T288853

Jdforrester-WMF changed the subtype of this task from "Task" to "Bug Report".

Hi! Would have to dive in to find out why/where it is not being set.

Here is the code in eventgate-wikimedia responsible for setting client_ip. And here is the function that determines client_ip from headers.

Just checking: is instrumentation explicitly setting http.client_ip in the event anywhere? If so that will take precedence.

From Slack:

It's worth noting that EventBus will only forward the client IP to the event intake service if one is present. I wonder if it is 🤔

Thanks, @Ottomata ! Re: whether instrumentation is explicitly setting http.client_ip - in terms of what the extension (WikiLambda) does, definitely not.

Also from Slack:

I think there might be something going on with client IP detection or forwarding. I would greatly appreciate some help.

The task that @Nettrom linked was about the ServerSideAccountCreation instrument. At the time, @Nettrom verified that the instrument had been fixed.

Fortunately, the instrument is still active so I ran the following via Superset:

SELECT
  SUM(1) AS n,
  SUM(IF(http.client_ip IS NULL, 1, 0)) AS n_null,
  SUM(IF(http.client_ip = '127.0.0.1', 1, 0)) AS n_127_0_0_1,
  SUM(IF(http.client_ip = '127.0.0.1' AND event.isapi, 1, 0)) AS n_127_0_0_1_api
FROM
  event.serversideaccountcreation
WHERE
  year = 2024
  AND month = 6
  AND day < 27
;

and got the following results:

n       n_null  n_127_0_0_1  n_127_0_0_1_api
178919  0       166129       14192

So…

  • A large number of events (92.85%) are being sent with X-Client-IP set to 127.0.0.1
  • This isn't limited to interactions with the MediaWiki Action API

Unfortunately, event.serversideaccountcreation data is purged after 90 days so it's difficult to detect when this started occurring

Can confirm that this problem has re-emerged in HomepageVisit as well, running the same query that @phuedx
used, but modified to remove the API counts and changed to query event.homepagevisit gives:

n	n_null	n_127_0_0_1
561611	0	518059

That's 92.2% of events having the IP set to 127.0.0.1.

phuedx raised the priority of this task from Medium to Unbreak Now!.Fri, Jun 28, 8:16 AM

One thought I did have was that EventBus's way of determining the client IP is different from other codebases. EventBus fetches the value of the X-Client-IP header directly. This is the only instance of this in all codebases indexed by Codesearch.

@Ottomata: Would you have any objection to changing the line to:

EventBus/includes/EventBus.php
if ( $this->forwardXClientIP ) {
    $req['headers']['x-client-ip'] = RequestContext::getMain()
        ->getRequest()
        ->getIP();
}

?

Change #1050588 had a related patch set uploaded (by Btullis; author: Btullis):

[operations/deployment-charts@master] Increase the eventgate canary log_level to trace, temporarily

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

Change #1050588 merged by jenkins-bot:

[operations/deployment-charts@master] Increase the eventgate canary log_level to trace, temporarily

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

Change #1050608 had a related patch set uploaded (by Btullis; author: Btullis):

[operations/deployment-charts@master] Revert "Increase the eventgate canary log_level to trace, temporarily"

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

Change #1050608 merged by jenkins-bot:

[operations/deployment-charts@master] Revert "Increase the eventgate canary log_level to trace, temporarily"

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

Change #1050632 had a related patch set uploaded (by Phuedx; author: Phuedx):

[mediawiki/extensions/EventBus@master] Forward info about original request

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

Change #1050632 merged by jenkins-bot:

[mediawiki/extensions/EventBus@master] Forward info about original request

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