[BUG] npm_config_... variables don't work for specifying a scoped registry password/auth/authToken
#64
Comments
|
Another problem with the current handling is that downcasing and dasherizing the keys could mess up URIs. So it seems like a fix in this area should also preserve the nerf-dart prefix. |
|
I believe the current downcasing is due to Windows portability concerns, since Windows env variable accesses are case insensitive. That said, it looks like the original case of the variable name is preserved, and some tests I did bear that out (under both PowerShell and CMD.exe contexts), i.e. given a |
|
One other portability note, Windows permits unusual characters in variable names -- e.g. you can set a variable named |
fixes npm#64 Don't normalize the registry prefix, don't dasherize the leading underscore of the nerfed key (e.g. `_password`) and don't downcase `_authToken`. This will allow you to successfully use env vars to control registry auth, e.g. `npm_config_//reg.example/UP_CASE/:_authToken=secret`
fixes npm#64 Don't normalize the registry prefix, don't dasherize the leading underscore of the nerfed key (e.g. `_password`) and don't downcase `_authToken`. This will allow you to successfully use env vars to control registry auth, e.g. `npm_config_//reg.example/UP_CASE/:_authToken=secret`
fixes npm#64 Preserve them verbatim since: 1. The URI path may be case sensitive 2. The URI may have underscores that should not be dasherized 3. The "_" sub-key prefix should not be dasherized 4. The sub-key should not be downcased (i.e. npm-registry-fetch expects `...:_authToken`, not `...:_authtoken` This will allow you to successfully use env vars to control registry auth, e.g. ``` env npm_config_//reg.example/UP_CASE/:_authToken=secret npm install ``` Although Windows env variable lookups are case insensitive, key retrieval/ iteration is case preserving, so we can reliably get the originally set key.
fixes npm#64 Preserve them verbatim since: 1. The URI path may be case sensitive 2. The URI may have underscores that should not be dasherized 3. The "_" sub-key prefix should not be dasherized 4. The sub-key should not be downcased (i.e. npm-registry-fetch expects `...:_authToken`, not `...:_authtoken` This will allow you to successfully use env vars to control registry auth, e.g. ``` env npm_config_//reg.example/UP_CASE/:_authToken=secret npm install ``` Although Windows env variable lookups are case insensitive, key retrieval/ iteration is case preserving, so we can reliably get the originally set key.
Is there an existing issue for this?
Current Behavior
npm_config_...variables don't work for specifying a scoped registry_password/_auth/_authToken. The keys are downcased, and the underscore after the colon gets converted to a dash, so you end up with nerfed-password,-auth, and-authtokenkeys, whichnpm-registry-fetchdoesn't know how to handle. AlthoughgetCredentialsByURIdoes have some special handling for-authtoken, it's never actually used when doing registry fetches.For example:
npm_config_username=foo->{ "username": "foo" }👍npm_config__password=bar->{ "_password": "bar" }👍 underscore is preservednpm_config_//my.registry.example/npm/:username=foo->{ "//my.registry.example/npm/:username": "foo" }👍npm_config_//my.registry.example/npm/:_password=bar->{ "//my.registry.example/npm/:-password": "bar" }👎 (note the-password, it should be_password)npm_config_//my.registry.example/npm/:_authToken=secret->{ "//my.registry.example/npm/:-authtoken": "secret" }👎 (note the-authtoken, it should be_authToken)Expected Behavior
npm_config_//my.registry.example/npm/:_password=bar->{ "//my.registry.example/npm/:_password": "bar" }👍npm_config_//my.registry.example/npm/:_authToken=secret->{ "//my.registry.example/npm/:_authToken": "secret" }👍Granted, using env vars named this way is perhaps questionable and non-portable, but based on my limited testing the approach generally works (apart from this bug 😅 ).
The value here is that env vars provide a reliable way to override local project config when you don't have a way to influence the command line args. If there were another mechanism to override project config WITHOUT using command-line args, that would also solve my current issue.
Steps To Reproduce
No response
Environment
No response
The text was updated successfully, but these errors were encountered: