#npm registry api

[npmjs]

Protect your npm account with two-factor authentication and read-only tokens

Today, we are announcing two new ways to protect your npm account. Please read on to learn how you can use these security features to keep your code safe and increase everyone’s trust in the more than 550,000 packages of code in the npm Registry.

Two-factor authentication (2FA)

Now, you can sync your npm account with an authentication application like Google Authenticator or Authy. When you log in, you’ll be prompted for a single-use numeric code generated by the app.

2FA is another layer of defense for your account, preventing third parties from altering your code even if they steal or guess your credentials. This is one of the easiest and most important ways to ensure that only you can access to your npm account.

Read-only tokens

If your continuous integration / continuous deployment (CI/CD) workflow includes linking your npm account to tools like Travis CI with authentication tokens, you can now create read-only tokens for tools that don’t need to publish. You can also restrict tokens to work from only specified ranges of IP addresses.

Even if your token is compromised — for example, if you accidentally commit it to GitHub — no one else can alter your code, and only authorized CI servers will be able to download your code.

Learn more about tokens in this doc: 

Working with Tokens

Set these up now (please)

The npm community is now larger than the population of New York City, so it’s never been more important to reinforce trust and encourage collaboration. Every developer who secures their npm account with these new methods helps ensure the safety and integrity of the code we all discover, share, and reuse to build amazing things.

Learn how to activate 2FA in this doc:

Using Two-Factor Authentication

Watch this space

There has never been a major security incident caused by leaked npm credentials, but our security work is never finished. We work continuously to protect the npm Registry and detect and remove malicious code, and we try to keep you informed of our efforts.

If you ever believe you’ve encountered any malicious code on the Registry or in npm itself, contact us right away [using the npm website](lgt security contact form) or by emailing [email protected]. If you have any feedback or questions about what we’ve rolled out today, just contact [email protected].

Thanks for helping keep the npm community safe.

UPDATE: To try out TFA, you'll need version [email protected] or newer of the npm client. To get it, run `npm install npm@latest -g`.

[npmjs]

basic auth to be limited soon

Since before the release of npm 2.0 in 2014 we have encouraged developers using our APIs to use token authentication instead of passing username and password in a basic auth header. Over the next few weeks we will be turning the recommendation into a requirement: basic http authentication will no longer work for any of the npm registry endpoints that require authorization. Instead you should use bearer tokens.

There are two exceptions:

The /login endpoint remains the endpoint to use to log into the npm registry & generate an auth token for later use.

The /whoami endpoint will continue to respond with the username for a successful login.

Both of these endpoints are monitored and rate-limited to detect abuse.

If you’re an npm user, this change will likely not affect you. Log in with the npm cli as you would normally:

npm login

A successful login will store an auth token in your .npmrc , which the client will use for all actions that require auth.

If you are using the npm cli to interact with registries other than npm’s, you should also not be affected. We have no plans to remove support for basic auth from the npm cli.

If you are a developer using npm’s API, make sure you’re using a bearer token when you need to authenticate with the registry. For more information about how to do this, please see the documentation for npm/npm-registry-client. This package is what the official command-line client uses to do this work.

If you have any questions or requests for us, please contact npm support. We want to hear about how you’re using our APIs and how you’d like them to evolve to support your use cases.

[npmjs]

CouchDB browse views unavailable

If you access /-/_view endpoints in the npm Registry, you have probably noticed that their availability has been low recently. We are temporarily suspending these endpoints and responding to them with 404s instead of the 504s you've been seeing. Our intent is to replace the service behind these endpoints with something more scalable. Unfortunately we have no estimates about when these endpoints will be available again.

The full list of deprecated endpoints is:

/-/_view/byKeyword

/-/_view/browseUpdated

/-/_view/browseAll

/-/_view/dependedUpon

/-/_view/browseAuthors

/-/_view/browseStarPackage

If you need regular, reliable access to this data, we strongly suggest that you mirror the public registry data by replicating the CouchDB at replicate.npmjs.com. The CouchDB JavaScript application that provides these views is available in the npm/npm-registry-couchapp repo. Follow the instructions in that repo and replicate from replicate.npmjs.com to get the full data set.

[npmjs]

API rate limiting rolling out

Please note: The content in this blog post is no longer applicable/has been deprecated. Feel free to contact us if you have any questions. 

Over the years our legacy APIs have not had rate-limiting built into them, other than the implicit, informal rate limiting caused by performance bottlenecks. Most of the time, for most users of our public APIs, this has been sufficient. As the registry grows, however, we’ve seen heavier use of our APIs, some of which has been heavy enough to prompt us to take action. If we can identify the user and suspect it’s a bug, we reach out. Sometimes we simply block IPs when the usage is at levels that affect other people’s ability to use the APIs.

This isn’t ideal, and we’d rather give clear signals to API users what the allowed rates are and when they are being rate-limited. We’re therefore rolling out more explicit rate-limiting for all registry apis. Your tools should be ready to handle responses with http status code 429, which means that you have exceeded the allowed limit.

We will be allowing logged-in users to make requests at a higher rate than anonymous users.

For some services we have already begun limiting the amount of data that can be requested at a time. For example, we limit package search requests to queries that are at least three characters long. We have also taken steps to prevent API users from exploiting bugs to work around that limit.

We’ve also re-instituted limits in our downloads API. Our previous implementation of this API limited data ranges to well under a year for performance reasons. Our current implementation performs much better but turned out to have its breaking point as well,. You may now request at most 18 months of data at a time for single-package queries. Bulk package data queries are limited to at most 128 packages and 365 days of data.

We reserve the right to further limit API usage without warning when we see a pattern of requests causing the API to be unusable for most callers. We’ll follow up with documentation in these cases. Our primary goal is to prevent API use from either deliberately or accidentally making the service unresponsive for other users.

All of our existing registry API documentation is available in the registry repo on GitHub, and you can find the most up-to-date statements about our rate-limiting policies there.