Override (default) token per call about node-cloudflare HOT 3 CLOSED

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.

from node-cloudflare.

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.

from node-cloudflare.

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.

from node-cloudflare.