Locking the Vault on Font Awesome NPM Tokens
“I’m not saying anything, I’m putting it in the vault, I’m locking the vault. It’s a vault!” —Seinfeld
Well, we thought we gave you a way to keep a secret better than George or Elaine, but it turns out that — in some cases — the vault combo was printed on the handle.
TLDR: We fixed a source of potential npm token leakage. If you’re a Pro customer who uses npm, you might wanna head over to your account services to regenerate a fresh npm token and then re-configure npm.
Now, what is Font Awesome Pro, the npm token, the impact when a token is leaked—and how do we get that vault locked once and for all?
Using NPM with Font Awesome Pro
Font Awesome Pro is a whole bunch more good stuff on top of the already great Font Awesome Free: lots more icons, more styles, and—especially relevant here—some extra services for accessing those icons, including our private npm registry.
If you’re a Font Awesome Pro customer, you can configure your Node.js projects to install Pro icons conveniently with npm, just like the rest of your packages. You just have to configure npm to use our private npm registry, authorizing with the npm token you can grab from your fontawesome.com account.
What If My NPM Token Has Leaked?
From a security perspective, we have determined that there is zero risk. An npm token does not provide access to your fontawesome.com account. Tokens are only used to authorize requests to npm.fontawesome.com which is an isolated service in our infrastructure.
From a data privacy perspective, the token cannot be used to identify an individual and therefore is not considered personally identifiable information (PII). Tokens are randomly generated unique identifiers and on their own provide no direct relationship to an account or individual.
It’s just that it could be used by an unlicensed person to access Font Awesome Pro. So it’s not the end of the world, but we should still clean it up.
Also, though we call it an “npm token”, that’s just because it gives you access to our private npm registry, but it has nothing to do with your npmjs.com account (if you have one of those).
What’s Happening Under the Hood
Initially, the way we instructed you to configure npm for our private registry involved setting the registry’s address to something like npm.fontawesome.com/2C116866-AAFB-DEAD-BEEF-0F3F2128F53A, where that part after the / is replaced with your npm token.
The problem is, when npm install runs and leaves behind its package-lock.json, or when yarn runs and leaves behind its yarn.lock, it includes that private registry URL, and since the URL includes the token, well…there’s the token right there in the lock file. And these lock files are normally checked in to source code revision, such as git, and then pushed up to a repository server, like GitHub.
That’s fine, as long as that git repo remains private. Our Pro license makes clear that you’re not allowed to use Pro icons in open source projects. So you might think: as long as I abide by the rule not to add Pro icons to open source projects, and therefore not to add my npm token to an open source project, then no npm tokens will end up in lock files on GitHub open source projects. Right?
Whoops
Turns out, when you configure it that way, you might unintentionally leak the token. Here’s how:
When you set npm configuration on a per-user basis, configuration settings that live in your $HOME/.npmrc, they are used across all your projects: both the private ones and the open source ones!
Suppose git repo X is private. Then suppose you want to add Font Awesome Pro to it, so you add something like npm.fontawesome.com/2C116866-AAFB-DEAD-BEEF-0F3F2128F53A as a private registry to your$HOME/.npmrc for any packages in the @fortawesome scope.
The npm token ends up in theyarn.lock file for git repo X and checked in to git. Fine, ’cause it’s all private so far.
But then suppose you switch to work on git repo Y, an open source project. To this one you add Font Awesome Free, which is totally cool to use in open source projects. But the Font Awesome Free npm packages also live under the @fortawesome npm scope. So, as a result of your per-user configuration, yarn will resolve those Free packages through the private npm registry as well, using that token, and store all of that in the yarn.lock file, which gets checked in to git…and pushed up to a public GitHub repo. D’oh!
Solution: Authorization Header
How can we solve this? Clearly, we gotta get that token out of the private npm registry URL. We can do that by using the same authorization mechanism that npm and yarn use after you npm login to a registry.
Instead of actually running npm login, though, we can just write the same kind of configuration and authorization keys to your .npmrc, and use your npm token as the authorization token.
So, just run these two npm config commands (using your own token, of course):
$ npm config set “@fortawesome:registry” https://npm.fontawesome.com/$ npm config set “//npm.fontawesome.com/:_authToken” 2C116866-AAFB-DEAD-BEEF-0F3F2128F53A
And here’s what ends up in your $HOME/.npmrc config:
@fortawesome:registry=https://npm.fontawesome.com/
//npm.fontawesome.com/:_authToken=2C116866-AAFB-DEAD-BEEF-0F3F2128F53AThe first line sets the URL for the npm registry to use for resolving the packages in the @fortawesome scope. The second line configures what authorization token to use when contacting that registry server. That’s the only place the npm token will appear. And since .npmrc is not a file that should be checked in to source control, you’re golden.
Under the hood, it just means that when npm or yarn make a request to npm.fontawesome.com they’ll add this HTTP header:
Authorization: Bearer 2C116866-AAFB-DEAD-BEEF-0F3F2128F53A(Yes, that’s a fake token. You should replace it with your real one.)
Updating and Deprecating
We’ve already released a new version of our private npm registry that looks for the Authorization header, so you should go ahead and switch over to it now. We’ve deprecated the old way, so eventually, it’ll stop working.
Also, if you think your npm token might have leaked, you can just generate a new one for yourself with the click of a button—and then re-configure npm to use this authorization mechanism.
—
** “npm token” in this post only refers to a code generated by fontawesome.com that gives a Font Awesome Pro customer access to our private npm registry. It has nothing to do with your npmjs.com account, if you have one.
