Do you want to request a feature or report a bug?
A feature
What is the current behavior?
I am using gemfury's private registry.
Authentication is enabled by setting the registry with :
yarn config set registry https://npm-proxy.fury.io/<MY_AUTH_TOKEN>/mirakl/
The problem is : When I install a dependency coming from this private registry, reigistry url is written in the yarn.lock. The whole path with the authentication token is imported and versioned in the yarn.lock in the resolved field of the dependency.
What is the expected behavior?
Whould it be possible either :
What I need is to setup authentication without interaction while repecting privacy.
Please mention your node.js, yarn and operating system version.
node : 8.9.1
yarn: 1.3.2
OS: Ubuntu 16.04
This would add a whole new layer of complexity, which in my opinion isn't worth it ATM. Because there are ways to avoid it.
@yarnpkg/core what do you think?
That's a pretty insecure way of handling access tokens. Error messages that output the URL are going to include the access token in the output, for example. Neither npm nor Yarn treat URLs as private/confidential like that.
URL is the primary identifier for a module, since there can be two registries that have a different module with the same name and version number. I don't think we're going to implement this as it would be specific to Gemfury and would be pretty burdensome in terms of maintenance (what if they change their URL format?)
Hello guys,
Thank you for your answers, I suppose that there will not be this problem with the npm registry.
Guys, please write here if you found any way to get rid of tokens from the yarn.lock file. We can't use yarn because of this security problem.
URLs are considered public material. You wouldn't put a password in a url, so don't put an access token.
Right, I understand, but there should be a way to separate URLs from authentication, I guess. Currently, yarn puts Gemfury URLs without token like this:
https://npm-proxy.fury.io/USERNAME/~/d/widget/widget-1.44.2#b594e705256e09a27e2a23e817677a9cab3b51c8, but it doesn't work on production, since your server should be authenticated on Gemfury to make a successful installation, at least I haven't found the way to adjust that it would work. I tried to use NPM_CONFIG_REGISTRY and YARN_AUTH_TOKEN, and both of them didn't work for me.
I understand that it's much more of a gemfury-specific problem, but still, there are lots of users, who want to be on the safe side and don't commit those tokens.
Have you tried setting your token by putting something similar in your .npmrc?
//npm-proxy.fury.io/:_authToken=00000000-0000-0000-0000-000000000000
No, I haven’t tried. I’m not sure if it’s a good way — to commit your auth token instead of using it through env variables 🤔
On 23 Mar 2018, at 13.34, Maël Nison notifications@github.com wrote:
Have you tried setting your token by putting something similar in your .npmrc?
//npm-proxy.fury.io/:_authToken=00000000-0000-0000-0000-000000000000
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
You would keep it in your $HOME without committing it but yeah, env variables would be nice (but a bit harder to specify on a by-host basis).
@lancedikson To avoid checking tokens into your .npmrc, you can use environment variable expansion:
//npm-proxy.fury.io/:_authToken=${FURY_TOKEN}
As a general rule, we now discourage using path-based tokens as described in the original issue. This was a holdover from the times before private-repo support in npm and Yarn. More here: https://gemfury.com/help/private-yarn
Most helpful comment
@lancedikson To avoid checking tokens into your
.npmrc, you can use environment variable expansion:As a general rule, we now discourage using path-based tokens as described in the original issue. This was a holdover from the times before private-repo support in npm and Yarn. More here: https://gemfury.com/help/private-yarn