- Rails Generate Secret
- Rails Generate Secret Key Base
- Rails Secret_key_base Generate Data
- Rails Secret_key_base Generate Money
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.
- Nowadays (rails 6) rails generate a secret key base in tmp/developmentsecret.txt for you. And in production environment the best is having SECRETKEYBASE as en env variable, it will get picked up by rails. You can check with Rails.application.secretkeybase.
- Answering my own question - secrettoken is used to prevent cookie tampering in Rails. Every cookie has a checksum saved with it, so users won't modify cookie contents (and change saved user id to steal someone's account, for example).
- Sep 17, 2015 Deploy Your Rails to OpenShift OpenShift is Red Hat’s Platform-as-a-Service (PaaS) that allows developers to quickly develop, host, and scale applications in a cloud environment.
Every time I try to deploy my app on Heroku I get an error 500:
Jul 09, 2019 attrencrypted gem is a popular tool for storing encrypted data in Rails apps. The problem is that adding it to your application includes over 2k external lines of code. What’s worse is that the project has not been updated for several months at the time of writing. An Engine with the responsibility of coordinating the whole boot process. Rails::Application is responsible for executing all railties and engines initializers. It also executes some bootstrap initializers (check Rails::Application::Bootstrap) and finishing initializers, after all the others are executed (check Rails::Application::Finisher).
Rails Generate Secret
![Rails secret_key_base generate data Rails secret_key_base generate data](https://qiita-user-contents.imgix.net/https%3A%2F%2Fcdn.qiita.com%2Fassets%2Fpublic%2Farticle-ogp-background-1150d8b18a7c15795b701a55ae908f94.png?ixlib=rb-1.2.2&w=1200&mark=https%3A%2F%2Fqiita-user-contents.imgix.net%2F~text%3Fixlib%3Drb-1.2.2%26w%3D840%26h%3D380%26txt%3DHow%2520to%2520set%2520up%2520the%2520secret%2520key%2520in%2520the%2520production%2520environment%2520in%2520Rails%25205.1%26txt-color%3D%2523333%26txt-font%3DAvenir-Black%26txt-size%3D54%26txt-clip%3Dellipsis%26txt-align%3Dcenter%252Cmiddle%26s%3Dc46dff1fe33be8a794c943a8677867d7&mark-align=center%2Cmiddle&blend=https%3A%2F%2Fqiita-user-contents.imgix.net%2F~text%3Fixlib%3Drb-1.2.2%26w%3D840%26h%3D500%26txt%3D%2540kawasaki%26txt-color%3D%2523333%26txt-font%3DAvenir-Black%26txt-size%3D45%26txt-align%3Dright%252Cbottom%26s%3D634f641f259b602a3e3149ae419b24d7&blend-align=center%2Cmiddle&blend-mode=normal&s=3843b09cc9b314206088f467a3290248)
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:- In the terminal of your production server execute the next command:This returns a large string with letters and numbers, copy that (we will refer to that code as GENERATED_CODE).
- Login to your server
- If you login as the root user, find this file and edit it:Go to the bottom of the file (“SHIFT + G” for capital G in VI)Write your environment variable with the GENERATED_CODE (Press “i” key to write in VI), be sure to be in a new line at the end of the file:Save the changes and close the file (we push “ESC” key and then write “:x” and “ENTER” key for save and exit in VI).
- But if you login as normal user, lets call it “example_user” for this gist, you will need to find one of this other files:These files are in order of importance, that means that if you have the first file, then you wouldn’t need to write in the others. So if you found this 2 files in your directory
~/.bash_profile
and~/.profile
you only will have to write in the first one~/.bash_profile
, because Linux will read only this one and the other will be ignored.Then we go to the bottom of the file (“SHIFT + G” for capital G in VI).And we will write our environment variable with our GENERATED_CODE (Press “i” key to write in VI), be sure to be in a new line at the end of the file:Having written the code, save the changes and close the file (we push “ESC” key and then write “:x” and “ENTER” key for save and exit in VI).
- You can verify that our environment variable is properly set in Linux with this command:or with:When you execute this command, if everything went ok, it will show you the GENERATED_CODE from before. Finally with all the configuration done you should be able to deploy without problems your Rails app with Unicorn or other.
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:
Rails Generate Secret Key Base
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 :
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
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 🙂
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
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:
Rails Secret_key_base Generate Data
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 Secret_key_base Generate Money
Everything worked out fine after I commented the following lines in the .gitignore file.