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 <westonplat...@gmail.com>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:
>>> richard....@gmail.com 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 rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to
> rubyonrails-core+unsubscr...@googlegroups.com.
> 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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
