11

Are both secret_key_base and secret_token needed for production in Rails 4.2? Setting neither causes the following exception message:

Missing secret_token and secret_key_base for 'production' environment, set these values in config/secrets.yml

The 4.2 upgrade guide (http://railsapps.github.io/updating-rails.html) says this:

When you create a new Rails application using the rails new command, a unique secret key is generated and written to the config/initializers/secret_token.rb file.

But no such file was created when I generated my app, and there is no reference to secret_token in config/secrets.yml

I'm assuming that the error message is wrong, and that only secret_key_base is needed. When I run my app in production on my dev machine, it starts with just secret_key_base, but in Engineyard, setting secret_key_base (via an environment variable) isn't working. I still get the error.

J Plato
  • 888
  • 1
  • 8
  • 17

4 Answers4

5

The problem you're seeing on Engine Yard is because the secret_key_base environment variable doesn't (yet) exist by default. That's something we're working on. You can put that in place on your own using custom chef; I suggest talking to our support team for more info on that.

As for the actual error you're getting, I just tested a brand new Rails 4.2 app ("rails new foo") to see if it's generating secret_token.rb, which it's not. I think what you need here is to create config/secrets.yml, and that file should look like this:

development:
  secret_key_base: somekey

test:
  secret_key_base: someotherkey

# Do not keep production secrets in the repository,
# instead read values from the environment.
production:
  secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>

Now, when you see ENV["SECRET_KEY_BASE"], that's where Engine Yard has a bit of a twist - we don't provide that out of the box yet. As long as your repo is private, you can hard-code something in there on your own. Otherwise, using custom chef could get you squared away by creating a secret key base and putting it in the wrapper script responsible for launching your app worker processes (so config/env.custom on our platform, for example).

Hope this helps.

J. Austin Hughey
  • 86
  • 1
  • 1
    Also, this may answer some of your questions about secret_token vs. secret_key_base: http://guides.rubyonrails.org/upgrading_ruby_on_rails.html#action-pack – J. Austin Hughey Feb 27 '15 at 14:37
  • Thanks for the quick response. I didn't get a secret_token.rb file when I generated the app, either (so I'm assuming it's no longer used), and my auto-generated secrets.yml file looks just like what you posted here. As for not supporting ENV["SECRET_KEY_BASE"] out of the box, can I use the dotenv gem rather than putting this in the file? – J Plato Feb 27 '15 at 14:53
  • The dotenv gem won't work on our platform because we have our own wrapper scripts that we use to set environment variables prior to execution of the application server (e.g. Unicorn). So while it'll work in development on your local machine, in production, you need to modify /data//shared/config/env.custom, which is a file that SHOULD be modified by custom chef since all files should be treated as disposable and config management is considered a best/required practice. – J. Austin Hughey Feb 27 '15 at 22:10
  • I had to create a secret_token.rb file and place my secret_token in there, except it loads it from the environment. That worked for me. – Nick Res Apr 06 '15 at 02:50
2

4.2 does use the secret key and the link you posted has the solution you are looking for.

In an environment that doesn't end up with the secret key active, you need to generate it using rake secret then place the output from the console into your config/initializers/secret_token.rb file (you can make one if there isn't one).

You have the option to avoid using secrets.yml. Many people prefer to use another gem/procedure (e.g. figaro) for handling secret info. To simplify your life you could just put this information into the secret_token.rb file and move on - or you can learn the various other idiomatic ways of handling the situation.

Ecnalyr
  • 5,792
  • 5
  • 43
  • 89
  • 1
    But why does the Rails error message say that both secret_key_base and secret_token need to be set? Is this just an error? And I'm using an environment variable to set secret_key_base in secrets.yml, rather than putting the key in the file. That way I don't have to gitignore it, and I don't have to manually re-create it on each deploy. – J Plato Feb 27 '15 at 14:31
  • @JPlato I think the error is just referencing secret_key_base and secret_token separately, but traditionally you would simply set secret_key_base within the secret_token.rb file. Honestly I'm not too sure about the specifics of the error, I just know that I have a 4.2 app up using this secret_key_base and barely noticed the configuration of it during my deploy process. So the solution must be simple and it seems like the error message is just making things seem more confusing than they need to be. I also updated my answer to be more clear. – Ecnalyr Feb 27 '15 at 14:49
  • 1
    Thanks, @Ecnalyr. I think your're right. I think the problem I'm having, per J. Austin Hughley's reply, is Engineyard's inability to set this through ENV. – J Plato Feb 27 '15 at 14:58
2

At least Rails 4.2.2 gave me the same error, but setting the environment variable SECRET_KEY_BASE in the rails user's .bash_profile file solved the problem for me, so the bit about secret_token seems to be bogus -- a holdover from earlier versions, probably.

Generate the secret by commanding rake secret, then use the generated string in file .bash_profile like this:

export SECRET_KEY_BASE='the_output_of_the_rake_secret_command'
Teemu Leisti
  • 3,750
  • 2
  • 30
  • 39
0

I'd suggest re-generating a new app with the latest version of Rails installed.

This file was auto-generated in my last project:

# config/secrets.yml
# Be sure to restart your server when you modify this file.

# Your secret key is used for verifying the integrity of signed cookies.
# If you change this key, all old signed cookies will become invalid!

# Make sure the secret is at least 30 characters and all random,
# no regular words or you'll be exposed to dictionary attacks.
# You can use `rake secret` to generate a secure secret key.

# Make sure the secrets in this file are kept private
# if you're sharing your code publicly.

development:
  secret_key_base: fooooo

test:
  secret_key_base: fooooo

# Do not keep production secrets in the repository,
# instead read values from the environment.
production:
  secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>

I'd also recommend that you compare the generated files via the railsdiff site (example: http://railsdiff.org/4.1.10.rc2/4.2.1.rc2) as it sounds like you're upgrading from an older version.

Michael De Silva
  • 3,808
  • 1
  • 20
  • 24
  • 1
    I'm using Rails 4.2.0, and I have the same auto-generated secrets.yml file you're showing. But per my question, where does secret_token come into play? The error message says to set both, which I'm assuming is incorrect. The upgrade guide says that a config/secret_token.rb file in generated -- does your app have one? – J Plato Feb 27 '15 at 14:27
  • 1
    You're referring an unofficial source - that railsapp site is out of date, hence the issue you're seeing. There's no `secret_token.rb` file created as per the app generator (by default that is). See answer by Austin Hughey for Engine yard specific info. Thanks! – Michael De Silva Mar 03 '15 at 12:53
  • 1
    OK, thanks, Michael. But FYI - the actual error message generated by Rails 4.2 also says that both need to be set (quoted in my original question), so it's a little confusing. – J Plato Mar 03 '15 at 17:05
  • Hey @JPlato, I recall seeing that - it may be an error in the reported error; possibly fixed by now. – Michael De Silva May 05 '15 at 08:13