[BUG] NPM v7 private registry authentication 401 (v6 works)

[Stvad]

Current Behavior:

While trying to install packages from GitHub package repository, I get 401 error when using npm v7 (tried with 7.3 and 7.4.2) while it's working with v6 (6.14.11)

Full error:

npm ERR! code E401
npm ERR! Incorrect or missing password.
npm ERR! If you were trying to login, change your password, create an
npm ERR! authentication token or enable two-factor authentication then
npm ERR! that means you likely typed your password in incorrectly.
npm ERR! Please try again, or recover your password at:
npm ERR!     https://www.npmjs.com/forgot
npm ERR!
npm ERR! If you were doing some other operation then your saved credentials are
npm ERR! probably out of date. To correct this please try logging in again with:
npm ERR!     npm login

npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2021-01-19T01_46_36_935Z-debug.log

My .npmrc is as follows:

//npm.pkg.github.com/:_authToken=<token>
//npm.pkg.github.com/:always-auth=true
@stvad:registry=https://npm.pkg.github.com

Seems very similar to #2183

Expected Behavior:

Packages are successfully installed

Steps To Reproduce:

Do npm install with npm v7, packages hosted in GitHub packages registry and .npmrc as mentioned above

Environment:

Happens to me both on macOS and in several Linux versions inside

• OS macOS 10.15.7/ Debian stretch
• Node: 15.5.1
• npm: 7.4.2

[MadeleineCodes]

I have the same issue on windows 10 trying to access azure feeds. I currently have:

[email protected]
[email protected]

I also tried some older 7.x.x versions, but none of them worked for me. Only if I downgrade to v6 it starts working again.

I keep getting

npm ERR! code E401
npm ERR! Unable to authenticate, your authentication token seems to be invalid.
npm ERR! To correct this please trying logging in again with:
npm ERR!     npm login

[wraithgar]

I was not able to duplicate this with v7.4.3

My config is as follows:

$ npm config list

@npm:registry = "https://npm.pkg.github.com" 
//npm.pkg.github.com/:_authToken = (protected) 
//registry.npmjs.org/:_authToken = (protected) 

The command I ran was npm install --prefer-online to ensure that this wasn't a case where caching was giving me a false negative. I also did this with no package-lock.json file present.

Is it possible that your package-lock has erroneous resolved urls that point to the registry that are left over from a previous setup/configuration?

[MadeleineCodes]

I tried again, removed package-lock.json and executed with npm i --prefer-online - same result. :/

[Stvad]

presence of package-lock.json does not seem to make a difference.
using npm install --prefer-online seems to help for me. I'm trying npm install on a clean docker image though, so I don't believe there are any cache?

[Stvad]

hrm interesting. if I do npm install --prefix-online on a clean image it doesn't work actually. but if I try doing npm install first (it fails) and then npm install --prefix-online it works 🙈

[MadeleineCodes]

Are there any news on this? --prefer-online doesn't work for me 😕
Also not if I first try with npm install...

[ianldgs]

I was having a similar problem as @Stvad. The first npm install would error and output the message of this issue, then, the second npm install would work normally.
Tried to give it a go because of the simpler workspaces implementation, would fit perfectly my use-case, but I was having so much problems that I gave up and will use yarn or nx.dev instead.

[wraithgar]

We would need more info to debug this, such as the output of the failing install with --verbose and the output of npm config list.

[MadeleineCodes]

npm install:

C:\workspace\playground\test>npm i --verbose
npm verb cli [
npm verb cli   'C:\\Program Files\\nodejs\\node.exe',
npm verb cli   'C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js',
npm verb cli   'i',
npm verb cli   '--verbose'
npm verb cli ]
npm info using [email protected]
npm info using [email protected]
npm timing config:load:defaults Completed in 3ms
npm timing config:load:file:C:\Users\mru\AppData\Roaming\nvm\v15.6.0\node_modules\npm\npmrc Completed in 2ms
npm timing config:load:builtin Completed in 2ms
npm timing config:load:cli Completed in 2ms
npm timing config:load:env Completed in 1ms
npm timing config:load:file:C:\workspace\playground\test\.npmrc Completed in 0ms
npm timing config:load:project Completed in 1ms
npm timing config:load:file:C:\Users\mru\.npmrc Completed in 2ms
npm timing config:load:user Completed in 2ms
npm timing config:load:file:C:\Program Files\nodejs\etc\npmrc Completed in 1ms
npm timing config:load:global Completed in 1ms
npm timing config:load:cafile Completed in 0ms
npm timing config:load:validate Completed in 1ms
npm timing config:load:setUserAgent Completed in 1ms
npm timing config:load:setEnvs Completed in 0ms
npm timing config:load Completed in 14ms
npm verb npm-session d8af380cdd26f605
npm timing npm:load Completed in 56ms
npm timing arborist:ctor Completed in 1ms
npm timing idealTree:init Completed in 820ms
npm timing idealTree:userRequests Completed in 0ms
npm timing idealTree:#root Completed in 1ms
npm timing idealTree:buildDeps Completed in 4ms
npm timing idealTree:fixDepFlags Completed in 0ms
npm timing idealTree Completed in 852ms
npm timing reify:loadTrees Completed in 1392ms
npm timing reify:diffTrees Completed in 47ms
npm timing reify:retireShallow Completed in 68ms
npm timing reify:createSparse Completed in 24ms
npm timing reify:loadBundles Completed in 0ms
npm http fetch POST 404 https://pkgs.dev.azure.com/myorg/_packaging/feed/npmregistry/-/npm/v1/security/advisories/bulk 886ms
npm http fetch GET 401 https://pkgs.dev.azure.com/myorg/_packaging/feed/npmregistry/uuid/-/uuid-8.3.0.tgz 1046ms
[many more 401]
npm timing reify:rollback:createSparse Completed in 22ms
npm timing reify:rollback:retireShallow Completed in 60ms
npm timing command:install Completed in 3797ms
npm verb stack Error: Unable to authenticate, need: Bearer authorization_uri=https://login.windows.net/5371663e-f24f-e240-aa39-65fb3ad05e3c, Basic realm="https://pkgsprodsu3weu.app.pkgs.visualstudio.com/", TFS-Federated
npm verb stack     at C:\Users\mru\AppData\Roaming\nvm\v15.6.0\node_modules\npm\node_modules\npm-registry-fetch\check-response.js:113:17
npm verb stack     at processTicksAndRejections (node:internal/process/task_queues:94:5)
npm verb statusCode 401
npm verb pkgid rimraf@https://pkgs.dev.azure.com/myorg/_packaging/feed/npmregistry/rimraf/-/rimraf-2.7.1.tgz
npm verb cwd C:\workspace\playground\test
npm verb Windows_NT 10.0.17763
npm verb argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "i" "--verbose"
npm verb node v15.6.0
npm verb npm  v7.4.0
npm ERR! code E401
npm ERR! Unable to authenticate, your authentication token seems to be invalid.
npm ERR! To correct this please trying logging in again with:
npm ERR!     npm login
npm verb exit 1
npm http fetch POST 404 https://pkgs.dev.azure.com/myorg/_packaging/feed/npmregistry/-/npm/v1/security/audits/quick 1126ms
npm verb audit error Error: 404 Not Found - POST https://pkgs.dev.azure.com/myorg/_packaging/feed/npmregistry/-/npm/v1/security/audits/quick
npm verb audit error     at C:\Users\mru\AppData\Roaming\nvm\v15.6.0\node_modules\npm\node_modules\npm-registry-fetch\check-response.js:123:15
npm verb audit error     at async Map.[getReport] (C:\Users\mru\AppData\Roaming\nvm\v15.6.0\node_modules\npm\node_modules\@npmcli\arborist\lib\audit-report.js:310:21)
npm verb audit error     at async Map.run (C:\Users\mru\AppData\Roaming\nvm\v15.6.0\node_modules\npm\node_modules\@npmcli\arborist\lib\audit-report.js:103:19)
npm verb audit error  HttpErrorGeneral: 404 Not Found - POST https://pkgs.dev.azure.com/myorg/_packaging/feed/npmregistry/-/npm/v1/security/audits/quick
npm verb audit error     at C:\Users\mru\AppData\Roaming\nvm\v15.6.0\node_modules\npm\node_modules\npm-registry-fetch\check-response.js:123:15
npm verb audit error     at async Map.[getReport] (C:\Users\mru\AppData\Roaming\nvm\v15.6.0\node_modules\npm\node_modules\@npmcli\arborist\lib\audit-report.js:310:21)
npm verb audit error     at async Map.run (C:\Users\mru\AppData\Roaming\nvm\v15.6.0\node_modules\npm\node_modules\@npmcli\arborist\lib\audit-report.js:103:19) {
npm verb audit error   headers: [Object: null prototype] {
npm verb audit error     'content-length': [ '29' ],
npm verb audit error     'content-type': [ 'text/plain; charset=utf-8' ],
npm verb audit error     p3p: [
npm verb audit error       'CP="CAO DSP COR ADMa DEV CONo TELo CUR PSA PSD TAI IVDo OUR SAMi BUS DEM NAV STA UNI COM INT PHY ONL FIN PUR LOC CNT"'
npm verb audit error     ],
npm verb audit error     'x-tfs-processid': [ '89f7068f-965d-4a2c-9d8f-5ca5933f4175' ],
npm verb audit error     'strict-transport-security': [ 'max-age=31536000; includeSubDomains' ],
npm verb audit error     'x-tfs-serviceerror': [ 'The+resource+cannot+be+found.' ],
npm verb audit error     'request-context': [ 'appId=cid-v1:f5d75a35-28cc-4e72-8007-1cf59e01402f' ],
npm verb audit error     'access-control-expose-headers': [ 'Request-Context' ],
npm verb audit error     'x-content-type-options': [ 'nosniff' ],
npm verb audit error     'x-msedge-ref': [
npm verb audit error       'Ref A: 7905DD0AC4334DFA809BB8F4E1C3D331 Ref B: PRG01EDGE0415 Ref C: 2021-01-19T06:20:49Z'
npm verb audit error     ],
npm verb audit error     date: [ 'Tue, 19 Jan 2021 06:20:48 GMT' ],
npm verb audit error     'x-fetch-attempts': [ '1' ]
npm verb audit error   },
npm verb audit error   statusCode: 404,
npm verb audit error   code: 'E404',
npm verb audit error   method: 'POST',
npm verb audit error   uri: 'https://pkgs.dev.azure.com/myorg/_packaging/feed/npmregistry/-/npm/v1/security/audits/quick',
npm verb audit error   body: ,
npm verb audit error   pkgid: 'quick'
npm verb audit error }
npm timing auditReport:getReport Completed in 2381ms
npm timing reify:audit Completed in 2382ms
npm timing npm Completed in 4413ms

and my .npmrc:

registry=https://pkgs.dev.azure.com/myorg/_packaging/feed/npmregistry/npm/registry/
username=mru
_password=THE_TOKEN
[email protected]
always-auth=true

If I switch back to any npm v6 version the exact same .npmrc works fine. So it does not seem to be an issue with the token/account or azure itself.

[ianldgs]

@wraithgar I was getting the information for you, but then I had to install npm 7 again, since I had downgraded.
Got 7.5.2 instead of 7.4.3 that I had before, and now my problem seems to be gone!

[wraithgar]

@ianldgs Glad to hear it. A bug fix went out in 7.5.2 that had to do with how and when the cli checked if you were logged in during publishes and that is likely why your specific case worked. I'm not totally sure it's related to the original issue yet because the error messages aren't the same as the other bug. ETA: it is 7.5.3 that has the bugfix, which is not out yet so now I don't know why your specific case worked, but it's good to know that it did. I'll see what else changed recently to try and find clues as I continue to debug.

I will try to replicate further with the new log/rc info given by @mrucelum

[wraithgar]

@mrucelum is that the actual output of npm config list? npm pulls from several different places when it builds its final config so just having the contents of one file may not tell the whole story.

[wraithgar]

Also, is your token newer than 90 days? Azure tokens only live for 90 days by default.

[leepowelldev]

Similar issues as logged here: #2619

Our CI pipelines are 401'ing - tokens are provided internally for the CI agents.

[wraithgar]

Thank you @leepowelldev, we can move the azure-specific conversation there, as this issue was for github packages.

[leepowelldev]

Sure - although the two issues may share similarities in how v7 is following redirects with auth?

[wraithgar]

I don't believe npm packages does redirects the same way azure does. I get a bare 200 response when fetching https://npm.pkg.github.com/@wraithgar%2fgh-registry-test with my auth token.

When I fetch the tarball urls from the github registry, they do redirect, but the new auth is baked into the query parameters as a signed aws request so it no longer is using my auth token after the redirect.

[leepowelldev]

Yeah, redirects are a guess on my part (I've not had time to investigate), however I don't think this is an issue with Azure as v6 works as expected.

[hoekma]

Having the same problem with the E401 immediately after upgrading to 7.5.2. I have a GitHub private store defined in ~/.npmrc. Everything works fine with [email protected]. Other factoids: MacOS 11.2 NVM 0.36.0, Node 14.15.4.

~/.nmprc:

registry=https://npm.pkg.github.com/myprivaterepo
//npm.pkg.github.com/:_authToken=myauthtoken

[MadeleineCodes]

I do not have other .npmrc files (as to my knowledge at least 😉), but just to be sure: here the original output from npm config list

; "user" config from C:\Users\mru\.npmrc

_password = (protected)
always-auth = true
email = "[email protected]"
registry = "https://pkgs.dev.azure.com/myorg/_packaging/feed/npm/registry/"
username = "mru"

; "cli" config from command line options

omit = []
user-agent = "npm/7.5.1 node/v15.8.0 win32 x64"

; node bin location = C:\Program Files\nodejs\node.exe
; cwd = cwd = C:\workspace\playground\test
; HOME = C:\Users\mru
; Run `npm config ls -l` to show all defaults.

Regarding the token: I am not sure when I created this token exactly, but I usually create tokens that last as long as possible. In case of azure this means 1 year. That doesn't prevent some of them stop working way before that for some reason 🤷‍♀️ - but I guess that's not the case here as the token works fine when using v6.

[theGlenn]

Still occurring on 7.5.2

[labbydev]

Still occurring on 7.5.3

[ljharb]

What about v7.5.4?

[tobiasbrenner]

Any update here? It's unbelievable how long this issue is unhandled. It's blocking our node & npm update for dev machines as well as our CI/CD docker images

[ungrim97]

Any update here? It's unbelievable how long this issue is unhandled. It's blocking our node & npm update for dev machines as well as our CI/CD docker images

I think that there are actually several issues in this ticket which is probably making it slightly more challenging to debug.

The issue we were seeing (which had the same symptoms as above) was that the syntax for declaring authTokens for repos had changed subtly such that you needed to namespace the tokens by repo using the // syntax

I recommend sticking some debugs into your npm config and npm install/publish js files and seeing if you can get more information out for your specific use case.

For me both publish and install from private repos works perfectly well with the change in syntax now for both NPM 7 and NPM 8 using an artifactory repo

[ungrim97]

A failing replicatable example would also be helpful. Lots of the above use private repos that obvs can't be used for debuging, so it would be helpful if someone could provide a replicatable example. If so I am happy to try and figure things out if needed.

[chriswhite199]

To chime in on this, with yet another solution that seems to fix it for me (against a private Artifactory instance) - I had to duplicate each auth entry with and without the port numbers in. This could be related to the Artifactory documentation, which if you follow the section on using Basic authentication, the response you get when calling the /auth/@scope endpoint seems to give you back the configuration with port numbers included (even if you don't make the curl call to a url with port numbers).

So in my case, my scoped entries included port numbers, which were being ignored by npm. If I duplicated the entries (without the specific port :443 in the url), or just stripped the :443 port number from the urls, it seemed to work.

# you don't even need this block if you are using a standard port (80 or 443 for the protocol scheme)
@SCOPE:registry=https://artifactory.mycorp.com:443/api/npm/repo-name/
//REGISTRY_URL_WITH_443/:_password=BASE_64_ACCESS_TOKEN or BASE_64_API_KEY
//REGISTRY_URL_WITH_443/:username=USERNAME
//REGISTRY_URL_WITH_443/:email=EMAIL (this line is not needed unless you plan to publish to the repo)
//REGISTRY_URL_WITH_443/:always-auth=true

# this block is needed - make sure you don't include default port values
@SCOPE:registry=https://artifactory.mycorp.com/api/npm/repo-name/
//REGISTRY_URL_WITHOUT_443/:_password=BASE_64_ACCESS_TOKEN or BASE_64_API_KEY
//REGISTRY_URL_WITHOUT_443/:username=USERNAME
//REGISTRY_URL_WITHOUT_443/:email=EMAIL (this line is not needed unless you plan to publish to the repo)
//REGISTRY_URL_WITHOUT_443/:always-auth=true

So a suggested way to mitigate against this inside npm would be handle default port mappings, so even if the user config entries include say :443 in the URLs, they are still loaded by npm if the url scheme it is trying to auth against uses this port by default.

[AlmondBro]

Confirming this is still broken for 8.1.2. Trying above possible solutions.

[ljharb]

@JuanDavidLopez95 v8.5.0?

[MadeleineCodes]

I can confirm that it works with the following configuration when using NPM 8.1.2 and azure feed as repository:

registry=https://pkgs.dev.azure.com/.../npm/registry/
always-auth=true
//pkgs.dev.azure.com/.../npm/registry/:_password=BASE_64_ACCESS_TOKEN
//pkgs.dev.azure.com/.../npm/registry/:username=USERNAME
//pkgs.dev.azure.com/.../npm/registry/:[email protected]

Both on dev machines (mac, windows) as well as in azure pipelines (ubuntu latest images).

One of our mac users had to also add

//pkgs.dev.azure.com/.../npm/npm/:_password=BASE_64_ACCESS_TOKEN
//pkgs.dev.azure.com/.../npm/npm/:username=USERNAME

Maybe that helps someone.

[AlmondBro]

Thank you @ljharb ! Had tried upgrading to v8.5.0 (thank you for informing of this, minutes within this release I presume! 🙂), but the same error resulted at the time.

Thank you @MadeleineCode! The above pattern inside the npm config file worked for me to avoid the npm error!

So it seems as if the pattern to get configs working with npm versions > 6, we have to specify the _password, username, and email after declaring a repository — awesome to know!

Thank you all so much again.

[Verc86]

I using:

[email protected]
[email protected]

I using a Sonatype Nexus Repository with

• a npm-group to get packages
• a npm-private to publish packages

I resolved E401 with this configuration on .npmrc:

strict-ssl=false
[email protected]
always-auth=true
_auth=<token>
registry=https://myServer/nexus/repository/npm-group/
@myscope:registry=https://myServer/nexus/repository/npm-private/
//myServer/nexus/repository/npm-private/:username=myUser
//myServer/nexus/repository/npm-private/:_password=<pswBase64>

This //myServer/nexus/repository/npm-private/:_authToken=<token> never work for me.

Maybe that helps someone.

[cmawhorter]

npm < 7 had a long-standing issue with hoisting dependencies, and the recommended fix for that issue (afaict) is to upgrade to npm >= 7. but this issue prevents that.

i'd like to ask that this issue be bumped in priority because there is no good workaround between those two bugs. i had to resort to manually patching package-lock.json and stick with npm6 to get things to install.

and FWIW -- #2918 provided a some other likely dupe issues: #2884, #3004

[leschdom]

Hi,

I also got confused by this behaviour, as we tried to update from node 14.19.0 (npm 6.14.16) to 16.14.0 (npm 8.3.1).

So our setup is as follows:

We have 3 packages from private GitHub repositories and have 2 tokens (2 packages can be retrieved with the same token, but are in different scopes)

My local ~/.npmrc looked like this:

cache=<some path to cache>
@scope1:registry=https://npm.pkg.github.com/scope1/
@scope2:registry=https://npm.pkg.github.com
@scope3:registry=https://npm.pkg.github.com

//npm.pkg.github.com/scope1/:_authToken=<TOKEN_1>
//npm.pkg.github.com/:_authToken=<TOKEN_2>

In the project we have this .npmrc:

registry=https://registry.npmjs.org/
@scope1:registry=https://npm.pkg.github.com/scope1/
@scope2:registry=https://npm.pkg.github.com
@scope3:registry=https://npm.pkg.github.com

Note that we add the tokens inside the pipeline via:

- echo "//npm.pkg.github.com/scope1/:_authToken=$TOKEN_1" >> .npmrc
- echo "//npm.pkg.github.com/:_authToken=$TOKEN_2" >> .npmrc

Now after switching to node 16.14.0 our pipeline suddenly failed:

npm ERR! 404 Not Found - GET https://npm.pkg.github.com/download/@scope1/<package_name>/<package_version>/<hash> - NPM package "<package_name>" does not exist under owner "scope1"
npm ERR! 404 
npm ERR! 404  '@scope1/<package_name>@https://npm.pkg.github.com/download/@scope1/<package_name>/<package_version>/<hash>' is not in this registry.

But locally it worked in the beginning, somewhere above it was mentioned that this could be due to caching (#2918). So after clearing my local cache, I was able to reproduce it as well.

So the solution that works for us is:

Updating the ~/.npmrc to include the scope

;before
@scope1:registry=https://npm.pkg.github.com/scope1/
@scope2:registry=https://npm.pkg.github.com
@scope3:registry=https://npm.pkg.github.com

//npm.pkg.github.com/scope1/:_authToken=<TOKEN_1>
//npm.pkg.github.com/:_authToken=<TOKEN_2>

;after
@scope1:registry=https://npm.pkg.github.com/scope1/
@scope2:registry=https://npm.pkg.github.com/scope2/
@scope3:registry=https://npm.pkg.github.com/scope3/

//npm.pkg.github.com/scope1/:_authToken=<TOKEN_1>
//npm.pkg.github.com/scope2/:_authToken=<TOKEN_2>
//npm.pkg.github.com/scope3/:_authToken=<TOKEN_2>

Updating the project .npmrc:

;before
registry=https://registry.npmjs.org/
@scope1:registry=https://npm.pkg.github.com/scope1/
@scope2:registry=https://npm.pkg.github.com
@scope3:registry=https://npm.pkg.github.com

;after
registry=https://registry.npmjs.org/
@scope1:registry=https://npm.pkg.github.com/scope1/
@scope2:registry=https://npm.pkg.github.com/scope2/
@scope3:registry=https://npm.pkg.github.com/scope3/

Updating the pipeline:

#before
- echo "//npm.pkg.github.com/scope1/:_authToken=$TOKEN_1" >> .npmrc
- echo "//npm.pkg.github.com/:_authToken=$TOKEN_2" >> .npmrc

#after
- echo "//npm.pkg.github.com/scope1/:_authToken=$TOKEN_1" >> .npmrc
- echo "//npm.pkg.github.com/scope2/:_authToken=$TOKEN_2" >> .npmrc
- echo "//npm.pkg.github.com/scope3/:_authToken=$TOKEN_2" >> .npmrc

I don't know why the old way worked with npm v6, but I'm also happy that I found a solution for our use case and wanted to share it with you.
Now it works locally and on our pipeline again! 😃

[LarsCelie]

I have seemingly the same issue. Although my setup is identical to a colleague, his setup works fine. CI pipeline works as well.
Seems to only affect my pc.

Reverting back to npm 6 works again.

[leschdom]

@LarsCelie, during my research I came across this article https://rapaccinim.medium.com/surviving-the-npm-err-404-with-private-packages-b413d80fb860 - maybe this helps in your case?

[LarsCelie]

@leschdom Thanks, but unfortunately, no.

[LarsCelie]

Apparently vsts-npm-auth was configured to use a different path (Manual override to %USERPROFILE%) than npm was looking for (HOME env). Making sure these were the same was the fix for me.

Still interesting that it worked for npm 6. Maybe as a fallback?

[pbriet]

Hello,

Has the same E401 issue with npm 7+ (was working correctly with npm 6)

The reason is that despite overriding registry in npm config, it was still using the "resolved" field from package-lock.json. For some reason, it was only affecting "@fortawesome/..."

Deleting package-lock.json was not an option for me.
Solution was to add the following in the CI : sed -i '/\"resolved\"/d' package-lock.json

[fredludlow]

I've been having a similar issue using a self-hosted gitlab instance - upgrading from npm 6.14.8 to 8.1 (also tried 8.6).

Apologies as this is somewhat gitlab specific so maybe off-topic:

In CI, an npmrc file gets built (based on a gitlab supplied template), including a port number in the URL. This was working fine for npm 6.x but, not 8.x. The change that fixed it for me was:

Before:

@${CI_PROJECT_ROOT_NAMESPACE}:registry=${CI_SERVER_PROTOCOL}://${CI_SERVER_HOST}:${CI_SERVER_PORT}/api/v4/projects/${CI_PROJECT_ID}/packages/npm/
//${CI_SERVER_HOST}:${CI_SERVER_PORT}/api/v4/packages/npm/:_authToken=${CI_JOB_TOKEN}
//${CI_SERVER_HOST}:${CI_SERVER_PORT}/api/v4/projects/${CI_PROJECT_ID}/packages/npm/:_authToken=${CI_JOB_TOKEN}

After:

@${CI_PROJECT_ROOT_NAMESPACE}:registry=${CI_SERVER_PROTOCOL}://${CI_SERVER_HOST}/api/v4/projects/${CI_PROJECT_ID}/packages/npm/
//${CI_SERVER_HOST}/api/v4/packages/npm/:_authToken=${CI_JOB_TOKEN}
//${CI_SERVER_HOST}/api/v4/projects/${CI_PROJECT_ID}/packages/npm/:_authToken=${CI_JOB_TOKEN}

I'm guessing that npm 8.x is normalizing my original https://my-server:443/bla/bla to https://my-server/bla/bla and then auth lookup fails?

[briiipr]

I can still confirm the same issue here: 401 Unauthorized error when updating to Node16+ and Npm8+ AND using a custom package feed*.

Works completely fine using Node12 and Npm6.

Just in case it makes a difference, myy setup includes: Azure CI/CD Pipeline with Docker-linux, Angular 13 and .NET 6

[bpcrao]

I cannot stop commenting on this since it took 8x3 = 24 hours so far.

[biyunwu]

We use a custom registry and my team leader faced this issue on node 16.8.0. They managed to fix it by reinstalling npm:
npm install -g npm-reinstall

[Slava-Ini]

Spent a lot of time and nerve to understand what is up with it.
After a while figured out that the same command npm config set _auth $TOKEN does complitely different things with v6 and v7 of npm.
On v6 it results to the following .npmrc

_auth="some_token"

which works perfectly with npm publish and such.

While in v7 it results to this .npmrc

//registry.npmjs.org/:username=some-user
//registry.npmjs.org/:_password=some-password

which breaks things.

So my solution is:

• Either use v6
• Or do echo "_auth=$TOKEN" >> ~/.npmrc" in v7

[jeoffreybakker]

We had a similar issue that after upgrading npm 6 to npm 8 we got authentication 401 errors on our private registry.
After digging around in the npm sources I found that the issue in our case was caused by a specific setup we had.

In our situation we had .npmrc file with an authToken in the root of the project (placed there during build time by our ci server).
In the package.json we had a dependency on git repository (git+https://github.com/wzr1337/angular-gestures.git#0.3.1)

What happen is the following nmp was able to clone the git repository in a temporary location. Than there is a check if the package.json in the dependency has workspaces or one of the following scripts postinstall, build, preinstall, install, prepack or prepare. If that is the case it will do a npm install on the temporary location where the project was cloned. At that moment the private repository was used to fetch the dependencies but without using the authentication token.

In our case we could solve the issue by moving the .npmrc file to the home directory of the user running the command.

[wraithgar]

This issue appears to be related to scoped/"nerf darted" auth config. npm 9 has tooling to help folks migrate off of these old configs and there are docs explaining it. If folks are still having auth problems in npm 9 feel free to open new issues with steps to reproduce

[agos]

@wraithgar can you link to the relevant documentation/info about the tooling? searching on Google how to migrate off the "old" config leads to... this issue.

[wraithgar]

npm config fix