cli icon indicating copy to clipboard operation
cli copied to clipboard

One-Off Dyno doesn't make CLI user available

Open adacosta opened this issue 11 months ago • 7 comments

Hi, I'd like to know who the authorized CLI user is, for a One-Off Dyno. Hopefully I'm wrong and it's available somehow.

I expect to be able to start a One-Off Dyno and see the user that created it from within the Dyno.

Example:

heroku run bash -a my_app
echo $HEROKU_ONE_OFF_USER
[email protected]

I imagine this could be implemented behind the scenes in the API by passing an ENV, if not already available in another way.

adacosta avatar Feb 11 '25 02:02 adacosta

Hi @adacosta -

heroku run printenv -a my_app will print all env vars for any Dyno. By default, no env var is set referencing the user that deployed the on-off Dyno but this can be explicitly set if desired by passing user information as an argument or environment variable when starting the dyno:

heroku run USER_EMAIL=$(heroku auth:whoami) ./your_startup_script.sh

heroku auth:whoami will print the email of the authenticated Heroku CLI user.

I hope this helps.

justinwilaby avatar Feb 11 '25 12:02 justinwilaby

@justinwilaby Could the assigning of USER_EMAIL be automatic so the ENV doesn't need to be specified? My current team has about half a dozen members, and we often have to spin One Off Dynos to run various console commands, but not all of our Heroku apps need this. It'd be nice if our auditing code (running on the dyno) could grab a USER_EMAIL. We're all familiar with running Heroku CLI commands and it's easy to forget inclusion of an ENV and also it's substantially more to type.

adacosta avatar Feb 11 '25 18:02 adacosta

Automated as in the Heroku CLI add this for you by default? Is there a technical reason this can't be scripted? npm run dyno:with:user

{
  //...
  "scripts": {
      "dyno:with:user": "heroku run USER_EMAIL=$(heroku auth:whoami) ./your_startup_script.sh"
    } 
}

justinwilaby avatar Feb 11 '25 19:02 justinwilaby

Right, it'd be nice if was automated by default. Having to put one more layer on top of the heroku command makes it so team members need to remember Heroku CLI commands for this one app differently than our other apps, so it'll be missed.

adacosta avatar Feb 11 '25 19:02 adacosta

I can mark this as a feature request which will prompt a discussion with the team.

justinwilaby avatar Feb 11 '25 19:02 justinwilaby

thank you @justinwilaby !

adacosta avatar Feb 11 '25 19:02 adacosta

Just to add a point in your feature request discussion @justinwilaby, being able to identify the Heroku CLI user from inside the one-off dyno would also allow using production console protection tools like Basecamp's console1984.

Also, does it really require some development on your end? I mean, couldn't we do it via a buildpack? 🤔

michaelbaudino avatar Aug 29 '25 15:08 michaelbaudino