Override (default) token per call

[boenrobot]

Let me start off with the use case... Auto wildcard SSL certificates via Let's encrypt.

In the current API model, zones can only be accessed by their ID (not by the DNS name), which can only be obtained with a call to zones.browse().

At the same time, a token can be made to either have read access to all zone OR read/write access to all zones OR read access to a single zone OR read/write access to a single zone. In other words, you can't make a single token have both read access to all zones AND read/write access to a single zone. You can however make two tokens - one that can read all zones, and one that read/write a single zone.

The only way to address this scenario right now is to have two clients - one for zones.browse(), and other for the other calls needed in the SSL procedure. But it would be a lot easier if SOMETHING changes.

In this case, I'm proposing what I think is the simplest change, which would be to allow the token to be overriden per call.

Though in terms of what CloudFlare as a whole should do, I think a token's permissions should be more flexible, i.e. allow them to both read all zones and read/write a certain sinlgle zone, and also, maybe allow zones.browse() for all tokens, but only list zones that the token can read or read/write. Or better yet, add a call that can get the ID(s?) from a given DNS name directly (that is available to any token with read access to the zone), so that a call to zones.browse() isn't even needed.

[terinjokes]

In this case, I'm proposing what I think is the simplest change, which would be to allow the token to be overriden per call.

You can already override credentials on a per-request basis using the Cloudflare Node.js bindings. An optional additional argument containing token, key, and email can be passed, and they'll be used for that request. This has been supported since v2.0.0.

Adapting the example from the README:

var cf = require('cloudflare')({
  token: 'your Cloudflare API token'
});

await cf.zones.read('023e105f4ecef8ad9ca31a8372d0c353', {
  token: 'different API token'
});

In the current API model, zones can only be accessed by their ID (not by the DNS name), which can only be obtained with a call to zones.browse().

In the case of auto-wildcard SSL with Let's Encrypt,you likely have a well-known list of domains you're renewing for. The zone IDs don't change, and can be obtained from the dashboard, so you can avoid zones.browse if necessary.

Though in terms of what CloudFlare as a whole should do, I think a token's permissions should be more flexible

Please make sure to make this suggestion to Cloudflare Support, so this idea can get to the teams responsible.

[boenrobot]

You can already override credentials on a per-request basis using the Cloudflare Node.js bindings. An optional additional argument containing token, key, and email can be passed, and they'll be used for that request. This has been supported since v2.0.0.

Good. Then the jsdocs should probably be updated to reflect that, as there's nothing in them to hint this is possible.

In the case of auto-wildcard SSL with Let's Encrypt,you likely have a well-known list of domains you're renewing for. The zone IDs don't change, and can be obtained from the dashboard, so you can avoid zones.browse if necessary.

True, but that's just not how general purpose ACME applications work like.

Taking greenlock as an example (since we're talking about node.js after all), it has a common interface for DNS plugins, whereby it gives them the targeted domain name, and what to do with it (set a record, read a record). Anything else specific to the DNS host (such as IDs) is up to the plugin to figure out from the provided DNS name. There are options when initializing the plugin, but that's set prior to knowing the domain names, applicable for all domains.

There's already a CloudFlare plugin for greenlock that does just that, and in fact, I was trying to patch it so that it supports tokens.

[terinjokes]

Then the jsdocs should probably be updated to reflect that, as there's nothing in them to hint this is possible.

PRs accepted. 😄

True, but that's just not how general purpose ACME applications work like.

Ok. I didn't have the context, and thought you were building something custom.

I'll consider this closed, since the ask has been answered.