On Friday, 11 January 2013 at 9:04 PM, Godfrey Chan wrote: > That would break essentially all rails applications that uses a git-based > deploy flow, such as Heroku and many other cap recipes. > > What might be a good idea though - is to use different secret token for each > environment, and allow that to be specified through an ENV variable, like how > the ActiveRecord connection parameters current work. There's nothing stopping you from having it in an ENV var today, that's one of the benefits of having it set in ruby code rather than
My::Application.config.secret_token = ENV['SECRET_TOKEN'] > I think it's quite important that the application secret isn't shared across > applications - and that includes development vs staging vs production > environments. I'm not really sure why it isn't implemented like what I > proposed in the first place. Perhaps there are some compatibility > requirements that I missed, but I couldn't think of any off the top of my > head. > > If people agree that this is worth pursuing, I can put together a PR. > There's really no additional risk to the secret being compromised when used in multiple applications / environments than there is when it's being used for multiple requests (which it is by definition). Having said that, I think one thing to experiment with is storing the secret in its own file in config. Perhaps config/application_secret.hex. If secret_token isn't set manually then read and decode it from that file. If you did that, then people who wanted to could put the application_secret file into their .gitignore and simply store and symlink the file as they do with database.yml. openssl rand -hex 40 > config/application_secret.hex Is a lot easier than having to generate a file containing the right constant names and sticking them in the initializers directory. > On Thursday, January 10, 2013, Weston Platter wrote: > > Following the recent Rails vulnerability, should the secret_token.rb be > > added by default to the .gitignore? > > > > -- > > 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/-/1SEW9p6io70J. > > To post to this group, send email to rubyonrails-core@googlegroups.com > > (javascript:_e({}, 'cvml', 'rubyonrails-core@googlegroups.com');). > > To unsubscribe from this group, send email to > > rubyonrails-core+unsubscr...@googlegroups.com (javascript:_e({}, 'cvml', > > 'rubyonrails-core%2bunsubscr...@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 > (mailto:rubyonrails-core@googlegroups.com). > To unsubscribe from this group, send email to > rubyonrails-core+unsubscr...@googlegroups.com > (mailto: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.
