Just because you can, and others do, doesn't necessarily make it a good idea.
By writing & encouraging developers to use the new `secrets` API, we expose them to a bad practise. Not only that, but other solutions exist (like using `Rails.application.config`). I'm not against configuration files per-say, I'm against secrets as persisted values in a codebase.
Presumably this would be treated just as `config/database.yml` is currently, i.e. `config/secrets.sample.yml` would be committed to the VC while `config/secrets.yml` would be ignored by the VC. When you deployed you would symlink from a shared (private) file to the secrets file.
Comments
No everyone likes that approach, some people prefers to save tokens in yaml files (see on github, you will find a dozen o plugins that do same thing)
Just because you can, and others do, doesn't necessarily make it a good idea.
By writing & encouraging developers to use the new `secrets` API, we expose them to a bad practise. Not only that, but other solutions exist (like using `Rails.application.config`). I'm not against configuration files per-say, I'm against secrets as persisted values in a codebase.
Doing this is bad: https://github.com/search?l=ruby&q=cookie_secret&ref=cmdform...
Presumably this would be treated just as `config/database.yml` is currently, i.e. `config/secrets.sample.yml` would be committed to the VC while `config/secrets.yml` would be ignored by the VC. When you deployed you would symlink from a shared (private) file to the secrets file.
Wouldn't the secrets file be added to gitignore?
it shouldn't be , because thats where some people will store their keys and others will reference their ENV variables.