Looks like can set ENV variables from Capistrano fairly trivially: http://craiccomputing.blogspot.com/2009/08/capistrano-and-environment-variables.html
API docs for Capistrano config: http://rubydoc.info/github/capistrano/capistrano/master/Capistrano/Configuration/Actions/Invocation -- Richard Schneeman http://heroku.com @schneems (http://twitter.com/schneems) On Sunday, January 13, 2013 at 3:59 PM, Jay Feldblum wrote: > Weston, > > I see using environment variables as the interface to configure your > application as the anti-Microsoft. As the Unix. It is simple to implement in > both the infrastructure (if you are implementing your own) and in your > application. > > The convention is not not Heroku-specific; it is specific to any application > which follows the convention of being configured via environment variables, > including Heroku applications, 12factor-style applications, > CloudFoundry-compatible applications, etc., and any application willing to > add two lines of code and a line of whitespace (see below). > > I'm not sure what's available for Capistrano, but anything that could set up > environment variables in a YAML file and symlink the YAML file into the > application, so that the application could read it on boot, would be good. > > Rails could even help this along, by natively supporting reading a > config/environment.yml file with environment variables. The file would be > gitignored by default and Capistrano could symlink in a production > config/environment.yml file when deploying. But it's easy to extend your own > application to try to read config/environment.yml early in the boot phase on > your own. > > # require gems w/ bundler > > # import environment variables > environment_yml = File.expand_path("../environment.yml", __FILE__) > ENV.update(YAML.load_file(environment_yml)) if > File.exist?(environment_yml) > > # setup app config based on environment variables as necessary > module MyApp > class Application < Rails::Application > config.something = compute_something_from(ENV) > end > end > > Rails supporting a RAILS_SECRET_TOKEN environment variable natively in the > generated secret_token.rb (or some other way, as well as a corresponding > environment variable for the old token so that you can do zero-downtime, > zero-session-clearing, key-rotation) may help the situation with > secret-tokens in public repos going forward. Two lines of code, a symlinked > YAML file with Capistrano or a config var on Heroku, and it's done. > > Cheers, > Jay > > On Sun, Jan 13, 2013 at 3:51 PM, Weston Platter <[email protected] > (mailto:[email protected])> wrote: > > @schneems. @jay. Good ideas. > > > > A fear that I have is that these conventions are Heroku specific, and not > > deployment agnostic. This feels enterprisely or Microsoft-ishy (or this > > feeling could be my own emotional baggage). > > > > To make this a Rails deployment convention and not just a Heroku, maybe > > make a capistrano equivalent to set the secret_token from a shell set > > variable? > > > > Thoughts? > > > > > > > > On Saturday, January 12, 2013 11:29:54 AM UTC-6, Jay Feldblum wrote: > > > Richard, > > > > > > That's overall the way I would go too, with two changes. > > > > > > 1. Name the environment variable RAILS_SECRET_TOKEN - i.e., prefixed with > > > RAILS_ - since an application may have many secret tokens unrelated to > > > session cookies. Environment variables related to a given library or > > > framework ought to be prefixed with the name of that library or > > > framework, such as RAILS_RELATIVE_URL_ROOT, to avoid easily-avoidable > > > conflicts and incompatibilities. > > > > > > 2. To support token rotation, there needs to be support for two tokens at > > > once: the current token and an old token. The old token, if it exists, > > > would be used to read session cookies in the HTTP request after the > > > attempt to read them with the current token fails, but the current token > > > would always be used to sign all session cookies in every HTTP response. > > > > > > Cheers, > > > Jay > > > > > > On Friday, January 11, 2013 3:18:14 PM UTC-5, richard schneeman wrote: > > > > I've talked at length with developers in Heroku, we're interested in > > > > making the default security of new Rails apps better out of the box. > > > > > > > > I know there is a much larger discussion going on and I believe there > > > > are one or more people actively looking into the options. I would like > > > > to work with anyone interested in security to figure out a good > > > > workflow with Heroku. One option we discussed would be automatically > > > > setting the a config var such as SECRET_TOKEN from the Heroku > > > > buildpack, so that it didn't matter if your source got exposed, they > > > > would need to get into your app as well. > > > > > > > > Being able to set the token from an environment variable could also > > > > allow services to rotate the token without having to modify any files, > > > > or touch anything you've got in Git. Just a thought. > > > > > > > > So again: feel free to ping me on twitter @schneems or in chat: > > > > [email protected] if you're working on security updates. I would > > > > like to help make the default experience secure and seamless. > > > > > > > > -- > > > > Richard Schneeman > > > > http://heroku.com > > > > > > > > @schneems (http://twitter.com/schneems) > > > > > > > > > > > > > > > > > > > > On Friday, January 11, 2013 at 5:29 AM, Rodrigo Rosenfeld Rosas wrote: > > > > > > > > > b > > > > > > > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Ruby on Rails: Core" group. > > To view this discussion on the web visit > > https://groups.google.com/d/msg/rubyonrails-core/-/p-g6xWy-HMEJ. > > > > To post to this group, send email to [email protected] > > (mailto:[email protected]). > > To unsubscribe from this group, send email to > > [email protected] > > (mailto:rubyonrails-core%[email protected]). > > For more options, visit this group at > > http://groups.google.com/group/rubyonrails-core?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to [email protected] > (mailto:[email protected]). > To unsubscribe from this group, send email to > [email protected] > (mailto:[email protected]). > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
