Iâve created a rails app (rails 4.1) from scratch and I am facing a strange problem that I am not able to solve.
Rails provides rake secret for just this purpose. The source code is here. The code simply requires SecureRandom and spits out a string. If you want to be really clever, you can pipe the string directly into your Vim buffer for the config file, with.! Check out rake -T secret inside. File.read(tokenfile).chomp else # Generate a new token and store it in tokenfile. Token = SecureRandom.hex(64) File.write(tokenfile, token) token end end SampleApp::Application.config.secretkeybase = securetoken I'm trying to follow the new Rails 4.1 way by using secrets.yml, and delete the secrettoken.rb.
Every time I try to deploy my app on Heroku I get an error 500:
Missing
secret_key_base for âproductionâ environment, set this value in config/secrets.yml
The secret.yml file contains the following configuration:
On Heroku I have configured an environment variable âSECRET_KEY_BASEâ with the result of ârake secretâ command. If I launch âheroku configâ, I can see the variable with the correct name and value.
Why am I still getting this error?
Thanks a lot
Answers:
I had the same problem and I solved it by creating an environment variable to be loaded every time that I logged in to the production server and made a mini guide of the steps to configure it:
I was using Rails 4.1 with Unicorn v4.8.2, when I tried to deploy my app it didnât start properly and in the unicorn.log file I found this error message:
app error: Missing `secret_key_base` for 'production' environment, set this value in `config/secrets.yml` (RuntimeError)
After some research I found out that Rails 4.1 changed the way to manage the secret_key, so if you read the secrets.yml file located at
exampleRailsProject/config/secrets.yml youâll find something like this:
This means that Rails recommends you to use an environment variable for the
secret_key_base in your production server, in order to solve this error you should follow this steps to create an environment variable for Linux (in my case Ubuntu) in your production server:
![]() Rails Generate Secret_key_base For Production Free
When you close your shell terminal and login again to the production server you will have this environment variable set and ready to use it.
And thats it!! I hope this mini guide help you to solve this error.
Disclaimer: Iâm not a Linux or Rails guru, so if you find something wrong or any error I will be glad to fix it!
Answers:
Iâm going to assume that you do not have your
secrets.yml checked into source control (ie. itâs in the .gitignore file). Even if this isnât your situation, itâs what many other people viewing this question have done because they have their code exposed on Github and donât want their secret key floating around.
If itâs not in source control, Heroku doesnât know about it. So Rails is looking for
Rails.application.secrets.secret_key_base and it hasnât been set because Rails sets it by checking the secrets.yml file which doesnât exist. The simple workaround is to go into your config/environments/production.rb file and add the following line:
This tells your application to set the secret key using the environment variable instead of looking for it in
secrets.yml . It would have saved me a lot of time to know this up front.
Answers:
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.
I had this exact same issue and it just turned out that the boilerplate
.gitignore Github created for my Rails application included config/secrets.yml .
Answers:
This worked for me.
![]()
SSH into your production server and
cd into your current directory, run bundle exec rake secret or rake secret , you will get a long string as an output, copy that string.
Now run
sudo nano /etc/environment .
Paste at the bottom of the file
Where
rake secret is the string you just copied, paste that copied string in place of rake secret .
Restart the server and test by running
echo $SECRET_KEY_BASE .
Answers:
While you can use initializers like the other answers, the conventional Rails 4.1+ way is to use the
config/secrets.yml . The reason for the Rails team to introduce this is beyond the scope of this answer but the TL;DR is that secret_token.rb conflates configuration and code as well as being a security risk since the token is checked into source control history and the only system that needs to know the production secret token is the production infrastructure.
You should add this file to
.gitignore much like you wouldnât add config/database.yml to source control either.
Referencing Herokuâs own code for setting up
config/database.yml from DATABASE_URL in their Buildpack for Ruby, I ended up forking their repo and modified it to create config/secrets.yml from SECRETS_KEY_BASE environment variable.
Since this feature was introduced in Rails 4.1, I felt it was appropriate to edit
./lib/language_pack/rails41.rb and add this functionality.
The following is the snippet from the modified buildpack I created at my company:
You can of course extend this code to add other secrets (e.g. third party API keys, etc.) to be read off of your environment variable:
This way, you can access this secret in a very standard way:
Before redeploying your app, be sure to set your environment variable first:
Then add your modified buildpack (or youâre more than welcome to link to mine) to your Heroku app (see Herokuâs documentation) and redeploy your app.
The buildpack will automatically create your
config/secrets.yml from your environment variable as part of the dyno build process every time you git push to Heroku.
EDIT: Herokuâs own documentation suggests creating
config/secrets.yml to read from the environment variable but this implies you should check this file into source control. In my case, this doesnât work well since I have hardcoded secrets for development and testing environments that Iâd rather not check in.
Answers:
You can export the secret keys to as environment variables on the
~/.bashrc or ~/.bash_profile of your server:
And then, you can source your
.bashrc or .bash_profile :
Never commit your secrets.yml
Answers:
What I did :
On my production server, I create a config file (confthin.yml) for Thin (Iâm using it) and add the following information :
I then launch the app with
Work like a charm and then no need to have the secret key on version control
Hope it could help, but Iâm sure the same thing could be done with Unicorn and others.
Answers:
I have a patch that Iâve used in a Rails 4.1 app to let me continue using the legacy key generator (and hence backwards session compatibility with Rails 3), by allowing the secret_key_base to be blank.
Iâve since reformatted the patch are submitted it to Rails as a Pull Request
Rails Generate Secret_key_base For Production List
Answers:
Iâve created
config/initializers/secret_key.rb file and I wrote only following line of code:
But I think that solution posted by @Erik Trautman is more elegant ðŸËâ°
Edit:
Oh, and finally I found this advice on Heroku: https://devcenter.heroku.com/changelog-items/426 ðŸâ¢â
Enjoy!
Answers:
this is works good https://gist.github.com/pablosalgadom/4d75f30517edc6230a67
for root user should edit
but if you non root should put the generate code in the following
Answers:
On Nginx/Passenger/Ruby (2.4)/Rails (5.1.1) nothing else worked except:
passenger_env_var in /etc/nginx/sites-available/default in the server block.
Source: https://www.phusionpassenger.com/library/config/nginx/reference/#passenger_env_var
Answers:
I had the same problem after I used the .gitignore file from https://github.com/github/gitignore/blob/master/Rails.gitignore
Rails Generate Model Foreign Key
Everything worked out fine after I commented the following lines in the .gitignore file.
Rails Generate Secret_key_base For Production OnlineJoin GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign up
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking âSign up for GitHubâ, you agree to our terms of service and privacy statement. Weâll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Commentscommented May 19, 2014
commented May 19, 2014
closed this May 19, 2014
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment
Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
December 2020
Categories |