3) Secrets.yml is great, no more worrying about adding your config.secret_token to the .env file when generating every single project.
How is adding config.secret_token to secrets.yml, which you're going to keep out of version control, so much better than adding config.secret_token to .env, which you're also going to keep out of version control? Both files need to be lugged around.
Secrets.yml is a one-toe-in-the-water solution. I hope next minor release we will just have dotenv in Rails for real.
Secrets.yml is in .gitignore by default, while secret_token.rb is not, right? Most (beginner) programmers don't think to implement something like Foreman which handles their secret tokens / API keys and commit them straight into their code. With it being standard in the Rails app, gems can rely on sending their secret keys into a file they know will not be committed by default.
As is, you need to remember to dig through all your initializers and copy out all the tokens (Devise, Omniauth, etc) and put them in a .env file
That makes sense, since database.yml is not going to contain any sensitive data anymore (passwords and usernames will be stored in secrets.yml), this file can be safely stored in repository.
I like this approach but there is a trade-off - you're an SQL injection away from losing your secrets, as opposed to a RCE or file reading bug when they're stored in .env. SQL injection bugs are more likely.
Comments
How is adding config.secret_token to secrets.yml, which you're going to keep out of version control, so much better than adding config.secret_token to .env, which you're also going to keep out of version control? Both files need to be lugged around.
Secrets.yml is a one-toe-in-the-water solution. I hope next minor release we will just have dotenv in Rails for real.
Secrets.yml is in .gitignore by default, while secret_token.rb is not, right? Most (beginner) programmers don't think to implement something like Foreman which handles their secret tokens / API keys and commit them straight into their code. With it being standard in the Rails app, gems can rely on sending their secret keys into a file they know will not be committed by default.
As is, you need to remember to dig through all your initializers and copy out all the tokens (Devise, Omniauth, etc) and put them in a .env file
That's fair. I can agree it is a nice optimization for the beginner Rails developer.
secrets.yml is not in .gitignore by default
Just checked -- you are right. I was using Rails Composer for one of the apps I checked, which does include it by default.
They also removed database.yml from the default .gitignore ... I don't understand why?
That makes sense, since database.yml is not going to contain any sensitive data anymore (passwords and usernames will be stored in secrets.yml), this file can be safely stored in repository.
I keep secrets in the DB. Only thing in the ENV that matters is DATABASE_URL. I'm surprised more people don't do this.
I like this approach but there is a trade-off - you're an SQL injection away from losing your secrets, as opposed to a RCE or file reading bug when they're stored in .env. SQL injection bugs are more likely.
We use figaro and have a table called variables that overrides the former. Also, we can restart the app from itself and see log files live.
Because secrets.yml is a better solution. A lot of rails developers have been using non-committed YAML files instead of .env anyway.
The environment variable pattern comes to most rails setups from Heroku (whether directly or inspired by it), not from the rails core team.