Feature: Local IP information in local cf object about miniflare

[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]

What if we exposed a "trustable" HTTP endpoint to get the cf object, then Miniflare could cache it in a file? If it fails to download, it would fallback to some hard-coded default.

This data doesn't change frequently, so the TTL could be really long.

[Electroid]

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

[mikechabotcandy]

@Electroid

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

Old thread -- but where is this URL officially documented?

[mrbbot]

Hey! 👋 Thanks for making such a thorough feature request. I like this idea, and it's been suggested before, but I have a couple of questions/concerns:

1. Where would we get the remote client IP address from? Presumably this would need to be a remote online service, breaking Miniflare's fully-offline promise. This probably isn't too much of a problem if this is an optional feature though.
2. I'd like to avoid making a geo IP database like fast-geoip a hard dependency, as these tend to be pretty large and go against Miniflare 2's goal of being lightweight. Again, as you suggest, we could do this by passing a path to an already downloaded database, or we could just make it an optional peer dependency.

[mrbbot]

That's a really good idea. Would automatically update if new fields are added to the cf object too.

[mrbbot]

Woah! That was quick! 🎉

[aaronsdevera]

What if we exposed a "trustable" HTTP endpoint to get the cf object, then Miniflare could cache it in a file? If it fails to download, it would fallback to some hard-coded default.

This seems to me like a somewhat elegant and simple solution!

However, a local geoip database would certainly be "more offline" than this additional call to a worker.

I suppose the use case I imagine is this:

• You are running miniflare on your own publicly accessible edge network
• Rather than completing an additional lookup, you would like IP info directly inline in the first request log

So fully completing the cf object isn't necessarily the goal, but rather the extension of miniflare as an edge services broker. Is this goal perhaps too tangential to the purpose of miniflare?

[e271828-]

+1 to this feature. It is necessary for accurate development simulation.

Also necessary for self-hosting compatible Worker scripts off-Cloudflare, which should ideally be part of the goal of any open source project dealing with a single-vendor code execution environment.

These databases can be fairly large, so suggest ensuring the design allows for the memory object to be efficiently shared across multiple Miniflare instances.

[mrbbot]

Hey! 👋 The first pre-release of Miniflare 2 has just been released, including this change. Request#cf is now fetched from https://workers.cloudflare.com/cf.json and there's a new metaProvider option that can be used for geo-IP lookups, assuming you're running Miniflare via its API:

const mf = new Miniflare({
  async metaProvider(req) {
    return {
      forwardedProto: req.headers["X-Forwarded-Proto"],
      realIp: req.headers["X-Forwarded-For"],
      cf: {
        // Could get these from a geo-IP database
        colo: "SFO",
        country: "US",
        // ...
      },
    };
  },
});

You can find the full changelog here and install it with npm i miniflare@next -D. Please let me know if you have any other issues, and feel free to ask questions in the #miniflare channel of the Cloudflare Workers Discord server.