Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Bearer token not sent when requesting tarball #5724

Closed
bcoe opened this Issue Jul 17, 2014 · 8 comments

Comments

Projects
None yet
4 participants
Owner

bcoe commented Jul 17, 2014

For npm Enterprise, we want to be able to authenticate reads as well as writes.

observed behavior

  • When npm install is executed, a request is made for the package JSON with an authorization header populated.
  • subsequently, when a request is made for the corresponding tarball, no authorization header is populated.

expected behavior

  • An authorization header should be populated so that we can authenticate tarball installs.
Contributor

othiym23 commented Jul 17, 2014

Is it a requirement that all requests to npmE be authenticated? The behavior can be changed such that all requests to a registry using bearer tokens will include the token, but this is a significant change from how traditional npm behaves.

Owner

bcoe commented Jul 17, 2014

We want to be in a position to authenticate reads/writes, so I think this behavior will be necessary.

Contributor

othiym23 commented Jul 17, 2014

OK, so fixing this is going to require a little work, because metadata loading goes through npm-registry-client, and tarball fetching uses lib/utils/fetch.sj, which uses request directly. Fixing this is going to probably involve moving fetch into npm-registry-client if this isn't to be a total hackaround. 🐴👺

tjwebb commented Jul 18, 2014

This would be fantastic generally for any sort of private mirror

Contributor

rlidwka commented Jul 20, 2014

I'm not familiar with how bearer tokens are used, but isn't it what always-auth=true does?

Contributor

othiym23 commented Jul 20, 2014

@rlidwka nope, bearer tokens are necessary for all requests, not just those dealing with metadata. This is a feature that's important for npm Enterprise, to guarantee that people installing packages from internet-accessible private registries are authorized to download them. There wasn't really a concept before of restricted access to package tarballs, which is how fetch survived not being part of npm-registry-client.

@othiym23 othiym23 was assigned by bcoe Jul 21, 2014

Contributor

othiym23 commented Jul 21, 2014

This work is happening on npm/npm-registry-client#54.

@othiym23 othiym23 modified the milestone: 2.0.0, 1.5.0 Jul 23, 2014

Contributor

othiym23 commented Aug 22, 2014

This work has been done for a while now, and is in the latest version of npm 2 (2.0.0-alpha.7 / 2.0.0-beta.0 for absolute newest version). The bearer token version has been tested pretty extensively, but the username:password version is not as heavily tested (and requires always-auth to be set to work properly, of course). Open a new issue if you find issues with it!

@othiym23 othiym23 closed this Aug 22, 2014

@othiym23 othiym23 removed the in progress label Aug 22, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment