@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


On Saturday, January 12, 2013 11:29:54 AM UTC-6, Jay Feldblum wrote:


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

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.

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
@schneems <http://twitter.com/schneems>

On Friday, January 11, 2013 at 5:29 AM, Rodrigo Rosenfeld Rosas wrote:


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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.

Search Discussions

Discussion Posts


Follow ups

Related Discussions



site design / logo © 2022 Grokbase