Wrangler: prefer environment variables over config file; require complete user config

Created on 2 Nov 2019  路  2Comments  路  Source: cloudflare/wrangler

per discussion https://github.com/cloudflare/wrangler/pull/471#discussion_r341769828:

we should be clear about precedence for user configuration; i.e., we need to explain what happens when you have both a config file and environment variables defined, and what happens if you have both token and global api key/email defined.

e.g. (strawman): if you have both a config file and env vars, env vars take precedence; if you have all three env vars defined, api token takes precedence.

category - feature priority - critical status - work in progress

Most helpful comment

So, our current idea is to have environment variables always override whatever auth is specified in a wrangler config file. That is, the following truth table would be observed:

Environment variables | Config file variables | Used auth method
------------------------------ | -------------------------- | ------------------------
token a | token b | token a
email b + key b | email a + key a | email b + key b
token a | email a + key a | token a
email b + key b | token a | email b + key b

This looks simple enough, but things get complicated when we think about when authentication information is partially provided:

Environment variables | Config file variables | Used auth method
------------------------------ | -------------------------- | ------------------------
email b + no key | email a + key a | throw error for missing key
no email + key b | email a + key a | throw error for missing email
email b + no key | token a | throw error for missing key
no email + key b | token a | throw error for missing email

^ I think this approach above makes sense; there should be NO case where email and key aren't in a 1-1 relationship, so if only one of the two is provided in an environment variable, we should throw an error.

We can also throw errors for empty keys, emails, or api tokens when wrangler config is run. This will prevent situations where someone puts an empty email and their real key in a config file and passes their email through an env var, which is a nonsensical use of wrangler in the first place.

All 2 comments

So, our current idea is to have environment variables always override whatever auth is specified in a wrangler config file. That is, the following truth table would be observed:

Environment variables | Config file variables | Used auth method
------------------------------ | -------------------------- | ------------------------
token a | token b | token a
email b + key b | email a + key a | email b + key b
token a | email a + key a | token a
email b + key b | token a | email b + key b

This looks simple enough, but things get complicated when we think about when authentication information is partially provided:

Environment variables | Config file variables | Used auth method
------------------------------ | -------------------------- | ------------------------
email b + no key | email a + key a | throw error for missing key
no email + key b | email a + key a | throw error for missing email
email b + no key | token a | throw error for missing key
no email + key b | token a | throw error for missing email

^ I think this approach above makes sense; there should be NO case where email and key aren't in a 1-1 relationship, so if only one of the two is provided in an environment variable, we should throw an error.

We can also throw errors for empty keys, emails, or api tokens when wrangler config is run. This will prevent situations where someone puts an empty email and their real key in a config file and passes their email through an env var, which is a nonsensical use of wrangler in the first place.

From ashley: I think including at minimum info logs indicating "found environment variables, using those" and "no environment variables, using config file at {}" would be helpful, even if all we get is the ability to use RUST_LOG=info
^ this is a good idea, let's make sure this is part of our implementation

Was this page helpful?
0 / 5 - 0 ratings