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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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%[email protected]> >>>>> 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%[email protected]> >>> 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 > [email protected] > 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 [email protected] For more options, visit this group at http://groups.google.com/group/heroku?hl=en_US?hl=en
