A question that arose in our meeting was how we intend to test ipinfo-view-full going forward. Some suggestions were:

• Test locally
• Use mock data (@phuedx was there a plan of how to do this?)

This will need a bit of discussion and possibly some more tasks (e.g. if we go the mock data route).

@dom_walden @imaigwilo flagging this for you.

In T270347#7511087, @Tchanders wrote:

• Use mock data (@phuedx was there a plan of how to do this?)

We'd update the IPInfoGeoIp2InfoRetriever service to return an instance of MediaWiki\IPInfo\InfoRetriever\StubGeoIp2InfoRetriever if a config variable (say $wgIPInfoEnableStubIPInfoRetriever) is truthy. I can think of two implementations for MediaWiki\IPInfo\InfoRetriever\StubGeoIp2InfoRetriever:

1. Always return data for a well-known IP address

// We extend GeoIp2InfoRetriever here because we're specialising its behaviour.
class StubGeoIp2InfoRetriever extends GeoIp2InfoRetriever
{
  private const IP = 'xxx.xxx.xxx.xxx';

  public function retrieveFromIP( string $ip ): Info {
    return parent::retrieveFromIP( self::IP );
  }
}

Which IP address should we use? MaxMind do use IP addresses in their test suites, e.g. https://github.com/maxmind/GeoIP2-php/blob/main/tests/GeoIp2/Test/Database/ReaderTest.php. Alternatively, Michael C suggests using the Pingdom probe server IP addresses as they're published and stable.

2. Always return well-known fake data

// We extend GeoIp2InfoRetriever here because we're specialising its behaviour.
class StubGeoIp2InfoRetriever extends GeoIp2InfoRetriever
{
  public function retrieveFromIP( string $ip ): Info {
    return new Info(
      [], // $coordinates
      64512, // $asn: 64512 - 65534 are 16-bit ASNs reserved for private use
      'Wikimedia Foundation', // $organization

      // ...

    );
  }
}

Just some thoughts on those two approaches:

1. Always return data for a well-known IP address

Pro: realistic data, won't need updating if Info structure changes
Con: IP address might stop returning data in future versions

2. Always return well-known fake data

Inverse of the above

In T270347#7632863, @Tchanders wrote:

Just some thoughts on those two approaches:

1. Always return data for a well-known IP address

Pro: realistic data, won't need updating if Info structure changes
Con: IP address might stop returning data in future versions

2. Always return well-known fake data

Inverse of the above

Unfortunately, we might not be able to do #1, because beta is missing so much IP data. For example, I have yet to find an IP which returns country information on beta.

We might have to do #2, even though we will have to be careful to keep updating its structure.

We might have to do #2, even though we will have to be careful to keep updating its structure.

I'm sure this will be fine - we can make sure it's well-commented. Thanks for looking into this @dom_walden

Moving this to blocked until we figure out a deployment timeline

@Niharika Is this task still valid?

• Administrators (users in the sysop group) on the Beta Cluster don't have the ipinfo right

Was there a legal reason to do this? It would make testing more difficult, as QA would need to wait for commits to arrive on testwiki, or test locally only.

If it is still needed, we should stall this task until we're no longer testing IPInfo on beta.

• Users in the ipinfo group on testwiki have the ipinfo right

I think we can remove this, since that group doesn't exist any more

• No users have the ipinfo-view-full on testwiki

Users do currently have this right on testwiki. Do we really want to remove it?

Thanks for catching this, Thalia. I don't think this task is valid as written anymore. I think we wrote this task when we said we will only give out IP Info to admins etc on testwiki and other wikis. We should be okay with the status quo for now. Maybe eventually when we have IP Info deployed everywhere, we can remove it from the beta cluster. How does that sound to you?