Add feature to securely access private npm repositories

BePo65 commented 4 years ago

Added new configuration variable (npmTokenEnvVar) and always send authorization header with bearer token when fetching data from npmjs registry.

Solves issue #22

BePo65 commented 4 years ago

I forgot to mention that I do not have access to a private npm repository and therefore could not test this feature.

kessler commented 3 years ago

The only thing that bothers me a little in this is that we "expose" the token... particularly since we use rc then people will provide the token as a command line argument, which will put it in a history file... that's not the best.

The only other solutions I can think of, that still uses rc and not some special other thinggy (which will be bad, since we do use rc all over the place) is to prohibit using the token as a cli argument. Maybe if it is provided as a cli argument we through an error or present a user input.

Personally I'm not very comfortable with environment variables either but I guess people do that...

WDYT?

BePo65 commented 3 years ago

I think I do have an error in my pull request. The configuration parameter should contain the name of the environment variable (with a useful default value) containing the token, not the token itself. This way we are flexible in respect of the name of the environment variable and we do not need to write the token into the command line. I will try to build kind of a test for this in the next days.

And of course you are right we should not put a token in the config via command line parameter or so. And environment variables have their deficits (e.g. the whole process can see them).

What does your experience say to using the name of an environment variable as a config parameter?

-----Ursprüngliche Nachricht----- Von: Yaniv Kessler [mailto:notifications@github.com] Gesendet: Mittwoch, 18. November 2020 04:43 An: ironSource/license-report license-report@noreply.github.com Cc: BePo65 bpottler@nexgo.de; Author author@noreply.github.com Betreff: Re: [ironSource/license-report] Add feature to securely access private npm repositories (#34)

The only thing that bothers me a little in this is that we "expose" the token... particularly since we use rc then people will provide the token as a command line argument, which will put it in a history file... that's not the best.

The only other solutions I can think of, that still uses rc and not some special other thinggy (which will be bad, since we do use rc all over the place) is to prohibit using the token as a cli argument. Maybe if it is provided as a cli argument we through an error or present a user input.

Personally I'm not very comfortable with environment variables either but I guess people do that...

WDYT?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ironSource/license-report/pull/34#issuecomment-729378692 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ABSHBQP24XLWE55X5C3PAVLSQM7C7ANCNFSM4SUJAV7A . https://github.com/notifications/beacon/ABSHBQNDX7EYSZKHOB5YGFLSQM7C7A5CNFSM4SUJAV7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOFN4W7BA.gif

BePo65 commented 3 years ago

Besides the question if using environment variables for authorization tokens is a good idea, I added a test for the proposed solution mocking https requests with 'nock'. Perhaps 'nock' could also be a solution for the ever changing versions on npmjs.org in the endToEnd tests of this project?

kessler commented 3 years ago

With regards to secret stuff in environment variables:

everyone uses env vars to store sensitive stuff, me too.
I don't like since it's a very exposed place. It's like writing that secret on a billboard's sidelines and hoping no one would notice.
When it's on my machine I totally abhore it but when it's in an environment like lambda or other relatively sterile places then it's more of a silent acceptence and "let's move on" kinda thing.

RE: nock

those changing versions are annoying for the tests no doubt...
mock everything up seems like a great solution, but it will also disconnect us completely from NPM and any changes they might have. Maybe we can just read package-lock.json in our json and use that as the expected results?

BePo65 commented 3 years ago

I agree in all points, but I think we need a solution for private repos anyway.

So I looked what kind of solution 'the web' has for this problem. I found lot of tools to administer secrets (e.g. hashicorp/vault or docker / kubernetes secrets). But in the end they all send the secrets to environment variables or mapped files (e.g. kubernetes) or use a tool specific api.

What would you use in a production environment?

How about

using a configuration parameter for the name of an environment variable containing the access token, plus
terminate with warning / error, if there is a parameter in config that corresponds to this environment variable, plus
using a configuration parameter for the name of a file containing the access token (which has priority over the first point), plus
waiting for a better solution ?-)

The solution with the file is what I use in my (very simple) container solution.

BePo65 commented 2 years ago

This pr is part of pr #65.

kessler / license-report

Add feature to securely access private npm repositories #34