Feature request: Authenticate with environment variable(s)

[Taytay]

I would like to use the CLI as part of some automated tasks. We are currently writing to the file manually :
echo "$CRUNCHY_BRIDGE_AUTH" > $HOME/.config/cb/api.crunchybridge.com

I'd prefer to be able to set the credentials in a way similar to how heroku or aws CLIs let me do it though. For Heroku I can just set the HEROKU_API_KEY environment variables, and AWS has their similar AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY.

[abrightwell]

We are currently discussing some related improvements around setting and storing credentials. I'll add this to that discussion for consideration.

[Taytay]

Thank you!

On a related note, I have just run across an instance where I appear to still be logged in (cb whoami returns a result) even though I've run cb login as someone else. I even tried removing the credentials stored in ~/.config/cb/api.crunchybridge.com, but cb whoami still reports that I am logged in. This seems to indicate that the credentials are being picked up somewhere/somehow, but I don't know how I've managed this. Are the credentials ever stored anywhere outside of ~/.config/cb/api.crunchybridge.com?

[abrightwell]

The credentials are only stored in the one place above. However, they are used to obtain a short lived access token. That token is stored in ~/.cache/cb/. What's probably happening is that the token is still 'valid'. As a short term work around you could probably just remove the token from that directory and cb will automatically refresh it with the new credentials the next time you run it. I'll make a note to discuss adding a logout in the near term.

[Taytay]

Ah, that's quite helpful. It was particularly confusing since I'd run cb login a second time and logged in with separate credentials, which I thought would do the trick. I appreciate the explanation and quick response.

[will]

I know there are some limits on the api to the rate you can use the "big" creds to get the 1 hour cookie-like access token that you actually use for the api.

I worry if we have env vars that use the big creds, people will quickly exhaust that limit. Maybe if we make cb login easier to use non-interactivly instead? Then a script would be like

cb login <creds> 
cb dosomestuff
cb logout

[Taytay]

Thank you for pointing that out!

I will admit that I am currently in danger of running across that same limit on the number of temporary credentials I can use, and it was surprising to me as well. I am "used" to Heroku, Github, and AWS APIs that allow me to generate semi-permanent API keys and secrets I can use until I revoke them. That fits my mental model as well as my security practices!

Since I must generate one of these short-lived tokens in order to use the API, when I was writing my scripts I am using my permanent credentials to generate one of these hour-long credentials at the beginning of the script. That works fine until I go to debug my script and run it a few times. My understanding is that if I run such a script more than 20 times in an hour, I'm going to start getting rejected. Given that I might be using the crunchy API to do automated tasks on a semi-frequent basis across multiple machines, this limit seems rather constraining and surprising. Furthermore, since my permanent credentials must live on these machines that are making automated use of the API, I don't believe anything has been gained from a security perspective. At the moment, requesting this temporary token just feels like a fragile hoop for my machines/scripts to jump through.

[abrightwell]

that allow me to generate semi-permanent API keys and secrets I can use until I revoke them.

There has been some discussion around this recently. I'm not sure of the direction it will go, but I can say it's been a consideration.

My understanding is that if I run such a script more than 20 times in an hour, I'm going to start getting rejected.

I suppose it depends on whether or not your script removes the short-lived token after every time it runs. If it doesn't then you should be good. If it does, then yeah, you'd likely run up against this wall. However, there has been discussions around increasing this limit. Though, noted that it wouldn't matter if the above model was available.

Furthermore, since my permanent credentials must live on these machines that are making automated use of the API, I don't believe anything has been gained from a security perspective. At the moment, requesting this temporary token just feels like a fragile hoop for my machines/scripts to jump through.

Similar to the Heroku, Github, AWS model you mentioned above, you can always reset/revoke these credentials and generate a new set. However, the point you make isn't lost on me.

[abrightwell]

@Taytay I just wanted to follow up with some of the above. Specifically the following:

Since I must generate one of these short-lived tokens in order to use the API, when I was writing my scripts I am using my permanent credentials to generate one of these hour-long credentials at the beginning of the script. That works fine until I go to debug my script and run it a few times. My understanding is that if I run such a script more than 20 times in an hour, I'm going to start getting rejected.

We have updated this in the API and you should no longer run up against this kind of limit. We hope this helps.

We're still discussing and working towards some of the other items. But, I at least wanted to give you a heads up on this recent update to the API.

I don't have any update on the original request at this time. But, we've made note of it and will continue to take it into consideration along side of other improvements to cb.