What Is the Use of Secret_Key_Base in Rails 4

What is the use of secret_key_base in rails 4

The secret_token.rb file's content includes a long randomized string which is used to verify the integrity of signed cookies (such as user sessions when people are signed into your web app).

Documentation says:

Use your existing secret_key_base from the secret_token.rb initializer
to set the SECRET_KEY_BASE environment variable for whichever users
run the Rails app in production mode. Alternately, you can simply copy the existing secret_key_base from the secret_token.rb initializer to secrets.yml under the production section, replacing <%= ENV["SECRET_KEY_BASE"] %>.

Since it is important file, and you can't put it to .gitignore, it is treated to be a good practice to use env variable to store secret_key_base value:

create .env or .powenv file and store it as:

export SECRET_TOKEN="9489b3eee4eccf317ed77407553e8adc97baca7c74dc7ee33cd93e4c8b69477eea66eaedeb18af0be2679887c7c69c0a28c0fded0a71ea472a8c4laalal19cb"

And then in config/initializers/secret_token.rb

YourAppName::Application.config.secret_key_base = if Rails.env.development? or Rails.env.test? # generate simple key for test and development environments
  ('a' * 30) # should be at least 30 chars long
else
  ENV['SECRET_TOKEN']
end

This article is (a bit old and) long but really full of useful info on the topic.

---

UPDATE 04.05.15

Starting from Rails 4.2 there is no longer secret_token.rb file.
By new convention there is a config/secrets.yml file aimed to store application's secrets.

Have a read on how to upgrade an existing app to 4.2.x according to innovations.

---

Technically the purpose of secrect_key_base is to be the secret input for the application’s key_generator method (check Rails.application.key_generator).

The application’s key_generator, and thus secret_key_base, are used by three core features within the Rails framework:

• Deriving keys for encrypted cookies which are accessible via
  cookies.encrypted.
• Deriving the key for HMAC signed cookies which are
  accessible via cookies.signed.
• Deriving keys for all of the
  application’s named message_verifier instances.

Check out more on each of the three in the article by @michaeljcoyne.

What's the correct way of defining secret_key_base on Rails 6?

The right way to access and check for secret_key_base in Rails 6 is no longer:~

Rails.application.credentials.secret_key_base

it now is:

Rails.application.secret_key_base

I'm not sure if this is Rails 6 or it's been like this forever. This becomes pretty clear when looking at this method, and its implementation:

https://github.com/rails/rails/blob/09a2979f75c51afb797dd60261a8930f84144af8/railties/lib/rails/application.rb#L410-L427

# The secret_key_base is used as the input secret to the application's key generator, which in turn
# is used to create all MessageVerifiers/MessageEncryptors, including the ones that sign and encrypt cookies.
#
# In development and test, this is randomly generated and stored in a
# temporary file in <tt>tmp/development_secret.txt</tt>.
#
# In all other environments, we look for it first in ENV["SECRET_KEY_BASE"],
# then credentials.secret_key_base, and finally secrets.secret_key_base. For most applications,
# the correct place to store it is in the encrypted credentials file.
def secret_key_base
  if Rails.env.development? || Rails.env.test?
    secrets.secret_key_base ||= generate_development_secret
  else
    validate_secret_key_base(
      ENV["SECRET_KEY_BASE"] || credentials.secret_key_base || secrets.secret_key_base
    )
  end
end

Both development and test mode have their own way of generating and storing the secret key base. For everything else, it pics it up from the environment, or credentials or secrets, in that order.

Set SECRET_KEY_BASE in production using a .env file

I too use dotenv gem. It works for me in almost all case.

This is my configuration of dotenv gem (yes, i put dotenv in Gemfile). I just create an aaaaa.rb initializer file.

config/initializers/aaaaaa.rb
#obscure name because rails load initializers/* files based on alphabets 
 require 'dotenv'
 Dotenv.load  

And, cases which it doesn't, i do this this finally in config/boot.rb file

ENV["SECRET_KEY_BASE"] = "foobar"

Rails: How to set secret key base on windows

I just ran into the same problem today. After some digging around I had it figured out.

According to this site, you can set your own environment variable by adding a .yml file then have your application.rb read the file.

I created a local_env.yml in /config and added the following code.

SECRET_KEY_BASE: your_key

Then in /local/application.rb add the following code.

class Application < Rails::Application
    .
    .
    .
    config.before_configuration do
        env_file = File.join(Rails.root, 'config', 'local_env.yml')
        YAML.load(File.open(env_file)).each do |key, value|
            ENV[key.to_s] = value
        end if File.exists?(env_file)
    end
end

You will probably want to add the local_env.yml to your .gitignore since it contain your key.

OR if you feel lazy....instead of <%= ENV["SECRET_KEY_BASE"] %>, just put your key there and .gitignore the secrets.yml

Unable to set secret_key_base for the production environment in Ruby on Rails 4.1.4 application running on Heroku

Add config/secrets.yml to version control and deploy again. You might need to remove a line from .gitignore so that you can commit the file.

.gitignore Github created for my Rails application included config/secrets.yml

---

OR

Follow this steps:

1. $ heroku config (run this command in your terminal)
2. Copy value from SECRET_KEY_BASE
3. paste value to secrets.yml file in place of <%= ENV["SECRET_KEY_BASE"] %> (without any quote)

e.g

production:
  secret_key_base: b1de60dd9e00816d0569c5ce3f8dbaa3c8ea4a7606120dc66cXXXXXXXXXXXXXXXXXXXXXX

4. re-deploy

Note: Actually this is not safe but in-case you just wanted to run your app temporary in production mode for testing or in emergency condition

I hope it works for you...

Missing secret key base for production environment

Found out that /etc/environment is ignored by apache2. Add the following to /etc/apache2/envvars solved my problem:

export SECRET_KEY_BASE=<the long string>

---

Related Topics