Good points. I'd say similar things apply for api keys, though not
entirely.
1. Every developer should have their own Heroku account as well.
2. The reason the key upload is require is (so far as I'm aware) just
for the purposes of git, and we have discussed perhaps allowing this
to work with api key stuff.
3. True, not sure how to get around this part. Although lately Github
has also been pushing for people to use https transfer and store the
password in keychain or something.
heroku login is required and automatically happens if you try to do
anything without having already done it. Also, after entering your
user/pass it already caches the api key locally. So if you look at
your ~/.netrc file you should be able to see you api key instead of
your password (though it is labeled as password due to limitations in
the netrc format).
I certainly understand your points as well, but I think that at the
moment things internally are leaning toward api key based consistent
auth. I'll keep your feedback in mind though.
Thanks!
wes
On May 10, 6:28 am, Daniel Doubrovkine <dbl...@dblock.org> wrote:
> I would definitely prefer the SSH key because:
>
> 1. Every developer already has one.
> 2. It's the preferred authentication with Heroku for the command line
> client, you have to upload your key when you set it up the first time.
> 3. It's the preferred authentication with Github and many other services
> developers use daily.
>
> All that said, what matters i the initial setup. Right now it means
> doing *heroku
> keys:add*. If I have to do *heroku login
> --save-my-api-key-to-local-machine-for-future-authentication-via-heroku-api *
> that
> might work too.
>
> cheers
> dB.
>
>
>
>
>
>
>
>
>
> On Tue, May 8, 2012 at 11:07 AM, geemus <wes...@heroku.com> wrote:
> > I'm happy to continue discussing pretty much indefinitely, I just didn't
> > want you to think I was blowing you off or not paying attention or
> > something.
>
> > I can certainly see the value of a single secret. I think we may actually
> > be moving more toward that model, but I think the defacto credential we
> > were settling toward was actually the API key. If there were only one
> > credential, but it was the API key, would that be satisfactory? Would you
> > prefer the SSH key as the single secret?
>
> > On Monday, May 7, 2012 2:05:43 PM UTC-5, dB. wrote:
>
> >> No, please, lets get going :) I really appreciate you replying. Something
> >> good will come out of this!
>
> >> I want users to have one single secret - their SSH key should let me
> >> obtain their API key, I don't want to store that anywhere. No?
>
> >> On Mon, May 7, 2012 at 11:46 AM, geemus <wes...@heroku.com> wrote:
>
> >>> I'm not sure what you mean exactly. You say that the API key is a
> >>> single key for all clients. Do all the developers use the same heroku
> >>> account? If they all have different accounts and API keys I think that
> >>> there are capabilities for controlling access in a bit more fine grained
> >>> way. I would also expect that the SSH key is the key to git usage, but
> >>> that the API key is key to everything else. As such I would expect that
> >>> each user would have their own and that they would need to have these
> >>> unique credentials locally to be able to utilize the API in the first
> >>> place. Is that not how you have structured things?
>
> >>> Sorry to be going, perhaps backwards there, but I didn't quite follow a
> >>> couple of your statements, so a little clarification would be great.
> >>> Thanks!
> >>> wes
>
> >>> On Friday, May 4, 2012 6:51:39 AM UTC-5, dB. wrote:
>
> >>>> Lets back-up for a second :)
>
> >>>> The point is that we don't want to hard-code any credentials on the
> >>>> client. You have an SSH key and that's the key to the kingdom. And it's
> >>>> your SSH key, not someone else's. And we want to be able to fetch
> >>>> variables
> >>>> from your default heroku application identified by a git remote.
>
> >>>> Heroku-api doesn't work like this, it wants an API key. It's a single
> >>>> key for all clients, and we don't want that. It would mean committing it
> >>>> to
> >>>> source control, not being able to kick out developers that leave the
> >>>> team,
> >>>> etc. So there would be two action items here: modify the code to support
> >>>> SSH auth, add code that figures out the default app from the git remote
> >>>> to
> >>>> this gem.
>
> >>>> Heroku client works like this, it uses your SSH credentials to
> >>>> authenticate. It also has the code to figure out the default heroku
> >>>> application from git remotes, but that code is buried in the gem and is
> >>>> not
> >>>> accessible unless you execute a command. This would need some refactoring
> >>>> to pull out the default application name.
>
> >>>> @geemus, what would you do?
>
> >>>> On Thu, May 3, 2012 at 6:00 PM, geemus <wes...@heroku.com> wrote:
>
> >>>>> That does make sense. The way I usually do something like that is to
> >>>>> set the rake task to just look for S3_BUCKET on my local machine as well
> >>>>> and then each developer could just export the appropriate environment
> >>>>> variable locally to make things work. You might want to namespace it a
> >>>>> bit
> >>>>> though, especially if you have multiple apps, to something like
> >>>>> MYAPP_S3_BUCKET, just to avoid conflicts.
>
> >>>>> That doesn't really answer the initial question though. I'm not
> >>>>> exactly sure what the best way to find the default app in a case like
> >>>>> that
> >>>>> would be. Perhaps there should be a command that would output it,
> >>>>> similar
> >>>>> to how you can use `heroku auth:user` or `heroku auth:token` to make the
> >>>>> client parse credentials and spit them out for you. Maybe something
> >>>>> like
> >>>>> `heroku apps:current` or something. Thoughts?
>
> >>>>> wes
>
> >>>>> On Thursday, May 3, 2012 10:48:47 AM UTC-5, dB. wrote:
>
> >>>>>> Take the example of a rake task that pushes a deployment to Heroku
> >>>>>> along with some S3 assets. Every developer has their own heroku
> >>>>>> application, and they configure it by creating a Heroku remote origin.
>
> >>>>>> To push to heroku a developer does do *git push heroku master*, then
> >>>>>> they need to push some assets to their own S3 bucket (eg.
> >>>>>> developer-bucket). The name of the bucket is configured as a S3_BUCKET
> >>>>>> variable on their heroku application. Right now we execute 'heroku
> >>>>>> config
> >>>>>> --long', parse that to figure out what the S3_BUCKET is, which is not
> >>>>>> ideal. Nowhere the Rake task knows the name of the remote Heroku
> >>>>>> application.
>
> >>>>>> Of course we could force every developer to hardcode the name of
> >>>>>> their application somewhere on the client, but we might as well keep
> >>>>>> our
> >>>>>> heroku config output parsing instead.
>
> >>>>>> Makes sense?
>
> >>>>>> On Wed, May 2, 2012 at 12:10 PM, geemus <wes...@heroku.com> wrote:
>
> >>>>>>> I'd actually recommend checking out the heroku-api gem for
> >>>>>>> programatic access. You can cover your example then this way:
>
> >>>>>>> require "heroku-api"
> >>>>>>> api = Heroku::API.new(:api_key => XXX)
> >>>>>>> api.get_convig_vars("my-app").******body
>
> >>>>>>> That said, I'm not sure what the best answer is on the default app
> >>>>>>> front. Could you describe how you intend to use this information? I
> >>>>>>> think
> >>>>>>> that might help me narrow down a recommendation and/or fix it up to
> >>>>>>> make it
> >>>>>>> easier to do what you need.
>
> >>>>>>> Thanks!
> >>>>>>> wes
>
> >>>>>>> On Tuesday, May 1, 2012 5:48:22 PM UTC-5, dB. wrote:
>
> >>>>>>>> I'm trying to replace some code in a Rake task that executes
> >>>>>>>> 'heroku config --long' and parses the output.
>
> >>>>>>>> I can do this:
>
> >>>>>>>> c = Heroku::Client.new(* Heroku::Auth.read_credentials)
> >>>>>>>> c.config_vars("my-app")
>
> >>>>>>>> Awesome, this returns the configuration variables for my-app as a
> >>>>>>>> Hash.
>
> >>>>>>>> The next problem is how to figure out the default app name - in
> >>>>>>>> development environments we often want to have our tasks run against
> >>>>>>>> our
> >>>>>>>> "default" development Heroku instance. The code I want to call is in
> >>>>>>>> lib/heroku/command/base.rb, ex********tract_app_in_dir(Dir.pwd).
> >>>>>>>> There's
> >>>>>>>> quite a bit of logic underneath this, storing git remotes and what
> >>>>>>>> not.
>
> >>>>>>>> 1. Do you think this should be refactored so that one can call
> >>>>>>>> extract_app_in_dir without an instance of a class?
> >>>>>>>> 2. Is there a simple(r) way to get the default app name?
>
> >>>>>>>> Thanks,
> >>>>>>>> dB.
>
> >>>>>>>> --
>
> >>>>>>>> dB. | Moscow - Geneva - Seattle - New York
> >>>>>>>> dblock.org <http://www.dblock.org> -
> >>>>>>>> @dblockdotorg<http://twitter.com/#!/dblockdotorg>
>
> >>>>>>>> --
> >>>>>>> You received this message because you are subscribed to the Google
> >>>>>>> Groups "Heroku" group.
>
> >>>>>>> To unsubscribe from this group, send email to
> >>>>>>> heroku+unsubscribe@**googlegroup****s.com<heroku%2Bunsubscribe@googlegroups
> >>>>>>> .com>
> >>>>>>> For more options, visit this group at
> >>>>>>>http://groups.google.com/**group****/heroku?hl=en_US?hl=en<http://groups.google.com/group/heroku?hl=en_US?hl=en>
>
> >>>>>> --
>
> >>>>>> dB. | Moscow - Geneva - Seattle - New York
> >>>>>> dblock.org <http://www.dblock.org> -
> >>>>>> @dblockdotorg<http://twitter.com/#!/dblockdotorg>
>
> >>>>>> --
> >>>>> You received this message because you are subscribed to the Google
> >>>>> Groups "Heroku" group.
>
> >>>>> To unsubscribe from this group, send email to
> >>>>> heroku+unsubscribe@**googlegroup**s.com<heroku%2Bunsubscribe@googlegroups.c
> >>>>> om>
> >>>>> For more options, visit this group at
> >>>>>http://groups.google.com/**group**/heroku?hl=en_US?hl=en<http://groups.google.com/group/heroku?hl=en_US?hl=en>
>
> >>>> --
>
> >>>> dB. | Moscow - Geneva - Seattle - New York
> >>>> dblock.org <http://www.dblock.org> -
> >>>> @dblockdotorg<http://twitter.com/#!/dblockdotorg>
>
> >>>> --
> >>> You received this message because you are subscribed to the Google
> >>> Groups "Heroku" group.
>
> >>> To unsubscribe from this group, send email to
> >>> heroku+unsubscribe@**googlegroups.com<heroku%2bunsubscr...@googlegroups.com
> >>> >
> >>> For more options, visit this group at
> >>>http://groups.google.com/**group/heroku?hl=en_US?hl=en<http://groups.google.com/group/heroku?hl=en_US?hl=en>
>
> >> --
>
> >> dB. | Moscow - Geneva - Seattle - New York
> >> dblock.org <http://www.dblock.org> -
> >> @dblockdotorg<http://twitter.com/#!/dblockdotorg>
>
> >> --
> > You received this message because you are subscribed to the Google
> > Groups "Heroku" group.
>
> > To unsubscribe from this group, send email to
> > heroku+unsubscr...@googlegroups.com
> > For more options, visit this group at
> >http://groups.google.com/group/heroku?hl=en_US?hl=en
>
> --
>
> dB. | Moscow - Geneva - Seattle - New York
> dblock.org <http://www.dblock.org> -
> @dblockdotorg<http://twitter.com/#!/dblockdotorg>
--
You received this message because you are subscribed to the Google
Groups "Heroku" group.
To unsubscribe from this group, send email to
heroku+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/heroku?hl=en_US?hl=en
