[BUG] No auth for URI, but auth present for scoped registry

[glen-84]

Current Behavior:

Getting:

No auth for URI, but auth present for scoped registry

.npmrc:

@x:registry=https://gitlab.com/api/v4/packages/npm/
//gitlab.com/api/v4/packages/npm/:_authToken=${GITLAB_NPM_TOKEN}

I read the wiki page, but I think that the tarballs are on the same host (https://gitlab.com). This is working with npm 7.10.0.

Expected Behavior:

No errors – auth should be available on the same host.

Steps To Reproduce:

Use the GitLab private registry with configuration similar to the above. I can provide more details if necessary.

Environment:

• OS: Windows 10
• Node: 14.16.1
• npm: 7.11.0

[nlf]

the error does not indicate that the host is different, but that the source of the data does not match your registry. it means that unless the uri to the tarball exists at some path that starts with https://gitlab.com/api/v4/packages/npm/ then we do not send authentication to it.

this is an effort to avoid sending authentication headers to addresses unless we are absolutely certain they match your provided registry.

did the logged error include the url that it attempted to fetch? if so, you can use that to determine what an additional entry in your .npmrc may need to look like to authenticate tarball requests as well.

[glen-84]

Ah, I see. There are a few references to host in that wiki article, so I was misdirected.

The URL is: https://gitlab.com/api/v4/projects/{projectId}/packages/npm/@x....

So I guess I need to add:

//gitlab.com/api/v4/projects/:_authToken=${GITLAB_NPM_TOKEN}

Please consider listing such breaking changes in a separate section of the changelog. The item under DEPENDENCIES is not very noticeable. 🙂

Thanks.

[glen-84]

One question: Could you just use a common prefix instead, if the origin is the same?

f.e. //gitlab.com/api/v4 covers both.

[JaxonWright]

I think this is the same as #3130

[glen-84]

I saw that issue, and I don't think that it's the same.

[isaacs]

#3130 is two problems. This is the same as one of them, but not the other ;)

Going to have a fix going out shortly.

[glen-84]

This appears to be fixed in 7.11.1. Thanks.