BREAKING(dotenv): Fix dot env permissions #3578
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Addresses #3572
Headline changes
restrictEnvAccessTo
configuration optionOverview
This is a breaking change, primarily to remove the
restrictEnvAccessTo
configuration option. To allow expansion of.env
variables to use values from the process environment, the original implementation read the entire process environment into memory. This mean all users of dotenv required the--allow-env
permission. Accessing all process variables was undesirable if you only needed to expand a single env variable, sorestrictEnvAccessTo
was added to restrict which env variables dotenv had access to and allow the granular--allow-env=SOME_VAR
to work properly. This setup deviates away from how Deno handles permissions.This change now allows for per-env-var access with no code configuration required and if you don't export any variables or expand any process variables then no
--allow-env
permissions are needed at all. The below examples show before and after permission handling:Permission example 1
#.env HELLO=world
Before change: Run with
deno run --allow-read --allow-env mod.ts
After change: Run with
deno run --allow-read mod.ts
Permission example 2
Before change: Run with
A=world deno run --allow-read --allow-env mod.ts
(full env access still required)After change: Run with
A=world deno run --allow-read --allow-env=A mod.ts
(granular access allowed)Permission example 3
Before:
Run with
A=world deno run --allow-read --allow-env=A mod.ts
(granular access only works with code grant toA
viarestrictEnvAccessTo
)After change:
Run with
A=world deno run --allow-read --allow-env=A mod.ts
(no code change required for granular access)Bug fix
When expanding a process environment var who value was blank, the existing code was setting the configuration value to undefined rather than empty string.
Before:
Run with
A= deno run --allow-read --allow-env mod.ts
yields:After change:
Run with
A= deno run --allow-read --allow-env=A mod.ts
yields:Additional consideration
As this is a breaking change, it may be desirable to consider #3561 as well, which would also be a breaking change to dotenv. However, as there is no feedback on that proposal to date no PR for that change has been progressed.