ERR_PNPM_FETCH_401

[devopsmash]

Hi,

I have an issue with pnpm, when I'm trying to install my private npm packages from my private npm registry (in this case AWS Codeartifact), I'm getting the error:

#11 32.53  ERR_PNPM_FETCH_401  GET https://<mydomain>-dom-<accountid>.d.codeartifact.us-east-1.amazonaws.com:443/npm/<myrepo>-repo/@<myorg2>/<mypackage>/-/<mypackage>-1.0.35.tgz: Unauthorized - 401
#11 32.53 
#11 32.53 No authorization header was set for the request.
#11 32.53 
#11 32.53 These authorization settings were found:
#11 32.53 @<myorg1>:registry=https://<mydomain>-dom-<accountid>.d.codeartifact.us-east-1.amazonaws.com/npm/<myrepo>-repo/
#11 32.53 @<myorg2>registry=https://<mydomain>-dom-<accountid>.d.codeartifact.us-east-1.amazonaws.com/npm/<myrepo>-repo/

here is my .npmrc:

registry=https://registry.npmjs.org/
@<myorg1>:registry=https://<mydomain>-dom-<accountid>.d.codeartifact.us-east-1.amazonaws.com/npm/<myrepo>-repo/
@<myorg2>:registry=https://<mydomain>-dom-<accountid>.d.codeartifact.us-east-1.amazonaws.com/npm/<myrepo>-repo/
//<mydomain>-dom-<accountid>.d.codeartifact.us-east-1.amazonaws.com/npm/<myrepo>-repo/:always-auth=true
//<mydomain>-dom-<accountid>.d.codeartifact.us-east-1.amazonaws.com/npm/<myrepo>-repo/:_authToken=<mytoken>

package.json:

...
"dependencies": {
    "@<myorg2>/<mypackage>": "1.0.35",
}
...

• node:18.14.0-bullseye-slim
• Linux
• pnpm version: 8.1.1

[joostdelange]

Hi there, this has been an issue for quite some time now (see pinned issue #2933).
I thought it was fixed recently from AWS CodeArtifact's side, but it seems I was wrong and this issue still occurs.

The reason we get this error is because somehow pnpm calls these private dependencies with the 443 port, which does not exist on CodeArtifact's side.

Downgrading to version 7.13.6 could temporarily fix this problem since this problem occurs since version v7.14.0:

pnpm will never reuse the registry auth token for requesting the package tarball, if the package tarball is hosted on a different domain.

So, for example, if your registry is at https://company.registry.com/ but the tarballs are hosted at https://tarballs.com/, then you will have to configure the auth token for both domains in your .npmrc:

@My-company:registry=https://company.registry.com/
//company.registry.com/=SOME_AUTH_TOKEN
//tarballs.com/=SOME_AUTH_TOKEN

Honestly I currently don't know what to do about this except for writing a script that duplicates the auth rule in your .npmrc and adds :443 after te base domain so pnpm finds a valid authentication token.

[devopsmash]

it's pretty interesting that my .npmrc file from above is working with npm install and with yarn install without any change.

I can open a ticket for AWS if necessary, just let me know what I need to ask them @joostdelange

[zkochan]

pnpm will never reuse the registry auth token for requesting the package tarball, if the package tarball is hosted on a different domain.

Maybe we can reuse the auth token if only the port differs. That shouldn't be a security vulnerability, I think.

[joostdelange]

@zkochan that sounds right indeed 👍

[jucian0]

Can you explain it for me?

[rkulinski]

pnpm will never reuse the registry auth token for requesting the package tarball, if the package tarball is hosted on a different domain.

Maybe we can reuse the auth token if only the port differs. That shouldn't be a security vulnerability, I think.

I encountered similar issue with private repository.

I think yarn and npm does it that (or similar) way. This problem can make migration to pnpm impossible. You can try to provide 443 port and it will work until --frozen-lockfile option is set (default on many CI systems).

[adcorduneanu]

Now I get 401 in customer registries in the following contexts:

1. I'm on a Windows registry and I have thousands of nodes that consume it... half of them are failing because of a mix of lower and upper cases. It's windows... we do not care about cases. This behavior appeared after pnpm 7.
   CustomOganization sometimes works, and sometimes customorganization works... but still relevant as we do not want this constraint

2. because I publish packages to my custom registry and when trying to install those the pnpm-lock.yaml is adding the tarball even though it should not as be configured by default, Even setting it manually in npmrc does not work. This tarball is forcing a 401 when restoring the packages (everywhere).

3. I do not understand why I have now to add the URLs with ports in the npmrc, as that worked fine before. Now I need to spend a lot of time on maintenance ... and I really want to know what was the purpose?!? also, I do not think you ever considered cases with server aliases - we are using a few of those as well...

As an ecosystem, we are using Windows, azure devops, with various setups, but all targeting the same version of pnpm (latest).

I do not really understand why changed something that worked perfectly before.