Skip to content
New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cli: put collector credential in a dotfile #1073

Open
tgeoghegan opened this issue Jun 6, 2024 · 2 comments
Open

cli: put collector credential in a dotfile #1073

tgeoghegan opened this issue Jun 6, 2024 · 2 comments

Comments

@tgeoghegan
Copy link
Contributor

In #1019, we're looking at making it easy and fun to run simple aggregations with Divvi Up with a few command line invocations. One rough edge we have is collector credential handling. We instruct users to do divviup collector-credential generate --save, which will write out something like ./collector-credential-11.json, and then subsequently that same path is passed to divviup api-client collect --collector-credential-file.

It'd be nice if we instead defaulted to storing credentials in files under ~/.divviup/ (or whatever $HOME is on a given OS), akin to how aws-cli will store authentication tokens and config for which token goes with which account in ~/.aws/{config,credentials}.

This could break compatibility with the tool's existing interface (where --save writes the credential to $PWD) but I think there are probably few enough users of this tool out there that we can afford to make incompatible changes.

@tgeoghegan
Copy link
Contributor Author

Definitely related to #1033, which questions the wisdom of writing secrets to stdout.

@inahga
Copy link
Contributor

inahga commented Jun 6, 2024

That more or less SGTM.

Consider that we expect collector credentials to be shared amongst a team. I think as long as we're transparent about where the collector credential is stored this shouldn't be too much of a problem.

This could break compatibility with the tool's existing interface (where --save writes the credential to $PWD) but I think there are probably few enough users of this tool out there that we can afford to make incompatible changes.

Yes, I don't have problems with rapidly making breaking changes until we find something that is nice and easy to use.

This was referenced Jun 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants