Feature: Local IP information in local cf object

Background

Deployed Cloudflare workers offer the useful cf object, which provides Cloudflare-specific data from their edge network. Among these is the ASN, ASO, country, of the remote client IP. This data is especially useful as it cuts out an extra step in look up this data with an external service.

Since miniflare is not deployed on the Cloudflare edge, it does not provide this data. In fact, this data is explicitly overridden in the file miniflare/src/index.ts (lines 375-395).

This feature seeks to explore ways to replace some of the data in the cf object.

Targeted sources files and dependencies

• miniflare/src/index.ts
  • contains the cf object and the overridden fields
  • this feature would alter the overridden fields to values from the locally ingested ip info
• local ip info ingestion
  • somewhere we would be allowing the ingestion of a local ip info db, such as a .mmdb
  • this could potentially be done from the command line interface like many of the other miniflare configurations as an optional CLI flag/arg

Benefits of this feature

• build consistent systems that rely on the Workers cf object for IP geo/whois data, even when running locally with miniflare

Risks of this feature

• the cf object is data from the Cloudflare edge network. Supplementing the data in the cf object with data sourced from elsewhere is potentially confusing at best, misrepresentation at worst.

Fields in cf object marked for IP info

Below are a list of fields within the cf object that could make use of data from a local IP geo/whois database. I have also subjectively marked them as either geo or whois as that may determine the database to be used.

• cf.asn: whois
• cf.asOrganization: whois
• cf.country: geo
• cf.city: geo
• cf.continent: geo
• cf.latitude: geo
• cf.longitude: geo
• cf.postalCode: geo
• cf.metroCode: geo
• cf.region: geo
• cf.regionCode: geo
• cf.timezone: geo

Reference materials

• Cloudflare Workers Docs: IncomingRequestCfProperties
• Accessing the cf object

[mrbbot]

Ah ok, that makes sense. Running miniflare on your own network is definitely a use case I’d like to support, especially now that Miniflare 2 lets you run multiple miniflare instances using the same (Redis) database and still maintain proper Durable Object transaction semantics. How about a function option like cfProvider that accepts a Node request object and returns values for the cf object and CF-* headers? This would default to using the (cached) trustable HTTP endpoint, but could be customised to use a local IP database.

[Electroid]

There you go! https://workers.cloudflare.com/cf.json