Multi-Account 2023-12-02 Feedback

[williammartin]

This discussion is a place for feedback to be left relating to #326. Please read the comment at #326 (comment)

[tekumara]

Thanks for all the great work!

Is there an env var I can set, similar to GH_HOST, that can be used to specify the user?

I use direnv and this would allow me to configure the user based on the current directory.

[williammartin]

Hey @tekumara, thanks for checking it out!

Currently no. We've considered both this and a global --user flag but we're not sure yet about the UX. There's already quite some precedence rules around credential related env vars and I have some concerns about user expectations around providing GH_TOKEN and e.g. GH_USER. Which should win if you provide both for authentication? What if a user provided a more privileged token, expecting to act as the GH_USER but saw permissions errors because we pulled their token out of the keyring? What about the interactions between GH_ENTERPRISE_TOKEN and GH_HOST in light of GH_USER? We're not ruling out the idea by any means, we just need to understand the use cases further.

That said, I expect that we will add the --user flag to gh auth token this week and I think (please correct me if I'm wrong), this will open the door for what you want without adding any extra confusion? Is there anything that GH_TOKEN=$(gh auth token --user $USER_FROM_DIRENV) gh ... wouldn't achieve for you?

[tekumara]

Thanks @williammartin for the quick response! And yes that would do the job.

As an aside, I do find gh auth token to be a security concern that allows the keychain to effectively be bypassed by an attacker, but that is a separate issue 🙂

[williammartin]

That's definitely a use case for us to take into consideration in the future, allowing the choice of user without exposure of the token. Thanks for the reminder on that issue and how it relates to the multi-account world.