lexicon
lexicon copied to clipboard
AnalogJ
Support Cloudflare API tokens
Cloudflare has introduced API tokens: https://community.cloudflare.com/t/restricted-api-keys/13647/100
Not to be confused with API keys.
Hi @teohhanhui @hongkongkiwi
Unfortunately I haven't been keeping up-to-date with all the new features that CloudFlare has released so thanks for bringing this up.
If I'm reading this correctly, it seems that Cloudflare is providing a way to scope their API tokens, which is great for security.
Looks like they are just standard Bearer tokens. Let me see what the requirements are to start using them with Lexicon.
Looks pretty simple actually, just a conditional around these two lines, https://github.com/AnalogJ/lexicon/blob/master/lexicon/providers/cloudflare.py#L141-L142
replacing the X-Auth-* header with an Authorization: Bearer XXXX header.
If one of you would be willing to open a PR to add support, that would be appreciated!
Since the "old" API keys require both username (email) and token (the key) and the "new" API tokens require just the token, I suppose the easiest solution is to assume the provided token (ie. LEXICON_CLOUDFLARE_TOKEN) is a "new" API token if the username (ie. LEXICON_CLOUDFLARE_USERNAME) is not provided, and otherwise assume it's an "old" API key. This way it would be compatible with existing implementations which use the "old" API keys without needing to use any "additional" properties/attributes/configs. At least I would prefer this kind of solution.
Is it possible to differentiate an old token from the new one? It is to avoid to interpret mistakenly a token as an old one if the username is still provided.
If it is the case, I agree with the multiple usage on the token parameter. If it is not, I would prefer a new attribute to have only one possible correct behavior.
why would you still be providing a username if you use the new tokens though? 🤔
Never look back on your system, and ask yourself "Hell, what is the use of this variable already?"
Never get mad at your JVMs that were all breaking for no reason, then realized you set JAVA_OPTS on weird values for a test done months ago?
If I have an occasion to avoid the system to behave inconsistently because of a forgotten environment variable, I take it :)
Well, I suppose you do test changes that you make, so it should come up quite quickly that something's wrong if things stop working when you change the environment variable to the new token. Of course you may have same or similar configuration in many places/environments that you forgot, but that should not be an issue if the "backwards compatibility" is not broken as the old "username + key" pairs keep working.
The reason I'd prefer using the "existing token variable" is to keep things consistent, it's called "token" on all DNS providers (that use tokens), and naming the token something else than "token" in this case would be both misleading and confusing. The existing keys "should" of course be called "key" rather than "token", but changing that now would break compatibility and cause issues on all setups where lexicon version is not locked and manual action is not taken, which is not good either.
I think the variable reuse with a "strict" condition of not supplying a username would be a decent compromise between the two; it won't break anything that weren't already broken, and it would use the right term ("token" for a token).
This is, of course, my personal opinion about the matter. In the end I'm happy with any decision as long as the tokens can be used through environment variables, like the keys can be now.
Is it possible to differentiate an old token from the new one?
I don't think so.
If it is not, I would prefer a new attribute to have only one possible correct behavior.
Unfortunately we already use LEXICON_CLOUDFLARE_TOKEN / LEXICON_CLOUDFLARE_AUTH_TOKEN for the "global API key". So we have a naming crisis now. :laughing:
OK I give up ;) All your arguments convinced me. Let's reuse LEXICON_CLOUDFLARE_AUTH_TOKEN!