Open monfresh opened 10 years ago
Alternatively, keep using secret_token.rb
and remove secrets.yml
. I personally prefer figaro for storing sensitive settings in ENV
in all environments. See this section for more details about the similarities and differences: https://github.com/laserlemon/figaro#is-applicationyml-like-secretsyml
Hi monfresh, I'm working on contributing to this issue, but am a little unclear on what you would like as the end result. Please let me know! Thanks :+1:
Hi Payam, I believe monfresh is stating that it's redundant to keep the secret_token.rb file now that the app is using the secrets.yml file. Section 2.3 of the following site explains it well - http://guides.rubyonrails.org/upgrading_ruby_on_rails.html
Furthermore, there is a discrepancy in secrets.yml in the configuration of the production environment variable once the upgrade was made to Rails 4.1. The variable set in the production environment would currently exist as: ENV['SECRET_TOKEN']
. As a result, you want the secrets.yml file to point to that variable. This is what it should look like:
secret_key_base: <%= ENV["SECRET_TOKEN"] %>
This is what it's incorrectly pointing to:
secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>
Hope that clears things up!
When the app was upgraded to Rails 4.1, it seems like
secret_token.rb
was left behind by mistake. It should probably be removed.Also,
secrets.yml
now points toENV['SECRET_KEY_BASE']
for production, but before the upgrade to Rails 4.1, the env var was calledSECRET_TOKEN
. This will cause issues during Heroku deployment. The env var should either stay the same, or a note should be added to the README.Thoughts?