-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] npm@10 refuses to install packages from GitHub package registry #7024
Comments
I have the same problem, npm v9 is OK, but npm v10 got error. |
Ive also got issues with Node 18.19 and npm 10. npm ci ... Error: Process completed with exit code 1. |
OK, this took HOURS to debug.
"node_modules/node-csv": {
"version": "0.5.0",
"resolved": "https://github.com/voodootikigod/node-csv/tarball/master",
"integrity": "sha512-dzSBhb1hyo0vijIe4ST7G0RFzqgjuIsTMDnw80+ygidl0q8ca+wBpnZH3FFWjqWHwzNJD2N7uJgfdmXks46G/A==",
"engines": {
"node": ">= 0.8"
}
}, I use corporate proxy to download dependencies.
After tricking
and in fact when I send a request to
I can also confirm that downgrading npm to v9 ( |
Nice @madmanxxx. I didnt have the time myself to do the extensive work you did. But yes, I can confirm this also. I'm using a corporate proxy, and trying to fetch a package from https://npm.pkg.github.com. We have to specifiy 18.18.2 Node version from docker hub, to make it work. |
I have the same problem, but it does not seem to be bound to GitHub package registries. I am using Azure DevOps artifact streams and get a 403 error when using npm 10 in combination with an HTTP proxy. Downgrading to npm 9 or removing the proxy "solves" the issue. Edit: I could narrow it down to version |
@lukasmahr The problem is not bound to any particular server, because the problem is within NPM. In fact I would even say that some servers (namely https://registry.npmjs.org/) are broken, because they tolerate malformed requests in the first place. By doing so the problem was very hard to debug. Reading your post again though I have second thoughts, because the problem reported by the server is HTTP 403, which in normal circumstances means access denied. To confirm the issue is caused by NPM you may try to send a request with malformed path and see what happens. |
@madmanxxx Indeed, it seems to be caused by the malformed path. I tested by running NPM with |
I have exactly same issue when install packages from github private packages via proxy. I have npm 10.2.5 installde. |
Also seeing the 400 Bad Request behind proxy with github package registry after updating npm. Btw: nodejs 20.9.0 seems to be the last version that bundles the working npm 10.1.0 according to https://nodejs.org/dist/index.json |
I am seeing similar behavior (404 Not Found) using npm 10.2+ with private NPM registries (JFrog Artifactory) and a corporate proxy. The issue does not appear with npm 9 or 10.1, when bypassing the proxy, or when using the "normal" NPM registry - all three factors are necessary. Request parameters in npm 10.1.0 (results in 304 Not Modified):
Request parameters in npm 10.2.3 (results in 404 Not Found):
The differences are:
Of these, only the first seems like a potential explanation, though it may be a red herring. |
I've also run into this issue with a private repository (using |
It seems #6901 is the same bug. My current workaround:
|
When using a proxy with the It appears that |
Same issue. I have a package-lock.json with lockfile version set to 3. Giving the same headaches with npm 10.2.3 as others here, but with azure devops packages. Changing the lockfile version to 1 does something different though... Adding another package never downloaded before on the machine, and having package-lock.json set back to lockfileVersion 3 still works (but then no cache cleared or node_modules removed). |
Behind a proxy, refreshed token, So without changing lockfileVersion. Thing I can think of is some internal variable or lower level http caching is playing a role here. Perhaps something with npm cli agent, as suggested by @rosen-dimitrov here? |
options.secureEndpoint is not always defined. There is however, a function to properly identify the type of connection in the base class, so intead of rolling the own check, relly on the base class implementation. Fixes npm#7024 Contributed by STMicroelectronics Signed-off-by: Torbjörn SVENSSON <[email protected]>
options.secureEndpoint is not always defined. There is however, a function to properly identify the type of connection in the base class, so intead of rolling the own check, relly on the base class implementation. Fixes npm/cli#7024 Contributed by STMicroelectronics Signed-off-by: Torbjörn SVENSSON <[email protected]>
options.secureEndpoint is not always defined. There is however, a function to properly identify the type of connection in the base class, so intead of rolling the own check, relly on the base class implementation. Fixes npm#87 and npm/cli#7024 Contributed by STMicroelectronics Signed-off-by: Torbjörn SVENSSON <[email protected]>
`options.secureEndpoint` is not always defined. There is however, a function to properly identify the type of connection in the base class, so instead of rolling the own check, rely on the base class implementation. Fixes npm/cli#7024 Contributed by STMicroelectronics
This isn't fixed yet; there's no shipped version of npm that resolves this issue. Please reopen. |
@grahamb issues on github are generally closed when the fix is merged, not when it's released. |
Yup, I'm aware of how auto-closing issues work. As the opener of this issue, however, I haven't confirmed it's fixed the issue, so it isn't "fixed" yet. |
I spent a few days looking into this issue and here are my findings: Using [email protected] I received 403s against my AzureDevops private NPM feed:
Using a MITM I was able to see that the following requests take place: GET https://myorg.pkgs.visualstudio.com/_packaging/MyRepo/npm/registry/somepackage/-/somepackage-8.12.0.tgz Which causes in a second GET request to the blob. The blob request includes an Authorization header and results in a 403 error:
Note that is above error was seen by our developers who authenticated using vsts-auth where a "Basic" auth token was passed as the auth header. Our build agent seems to pass a "Bearer" token and resulted in a slightly different error (this time it's a 400):
However, using [email protected] the same request to the blob does not include an Authorization header and it succeeds with a 200 response. I even replayed my request that resulted in the 403 in postman, disabled just the Authorization header, and it succeeded. My team has seen very intermittent behaviour. Sometimes things work, sometimes they don't. But I guess we'll stop asking questions and simply use [email protected] until things stabilize. |
I gave up on this issue getting fixed and switched over all of my repos and CI/CD system to use |
This fix was included in v10.5.0 (bundled with Node 21.7.1). |
Thanks for mentioning! I hope the fix will land very soon in node v20 and v18 as well. |
I can confirm that [email protected] fixes the issue for me as well. I second the hope for it landing in Node LTS as well. |
I third that 10.5.0 lands in Node 20 |
Works well with npm 10.5.0 |
In my Dockerfiles running in a CI/CD system on
|
Is there an existing issue for this?
This issue exists in the latest npm version
Current Behavior
npm@10 is not installing packages from a private GitHub Enterprise Server registry. It fails with a 403 forbidden error when trying to fetch the package. Previous versions of npm do not encounter this issue.
Expected Behavior
I should be able to install packages from a private registry when my
.npmrc
is configured properly.Steps To Reproduce
Remove ~/.npm to ensure we're not pulling from cache
Configure
.npmrc
to use a private registry (in this case, I am using GitHub Enterprise Server 3.9.3)Install a package from the private registry:
Debug log: 2023-11-25T00_29_42_285Z-debug-0.log
When using npm v9, this error does not occur. For example, with Node 18/npm 9:
Using npm v10 with node 18 fails with the same 403.
Use npm v9 with node 21 works.
This seems to indicate that something has changed with npm 10 with how it handles private registries (or at least with GitHub's registry).
Environment
The text was updated successfully, but these errors were encountered: