Closed jandudulski closed 9 years ago
killer con - Can't override secrets with ENV
killer con - Can't override secrets with ENV
:(
ENV FTW.
@teamon wat?
development:
secret_key_base: c7c33ccb8419f37f5ab17e0206da824d707c97e3f8203b118a1b9d410a518c8aadd80f0060ce3116524e94f87fae95cbaef78becef8929742782eaef6c8d7483
test:
secret_key_base: 218738f30ed0a9ef3d39c4f7a2a366afddece230ad609433ee28198b32584970f67cffb7028fd6c562bcac4f3c859e72e472edfefa6c2364975d35f0d60c4e65
# Do not keep production secrets in the repository,
# instead read values from the environment.
production:
secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>
meh, rails_config once again :/
Why?
My current solutions looks like this:
default: &default
secret_key_base: <%= ENV.fetch("SECRET_KEY_BASE") %>
something_else: <%= ENV.fetch("SOMETHING_ELSE") %>
development: *default
test:
<<: *default
secret_key_base: 218738f30ed0a9ef3d39c4f7a2a366afddece230ad609433ee28198b32584970f67cffb7028fd6c562bcac4f3c859e72e472edfefa6c2364975d35f0d60c4e65
production: *default
And secrets is in repo. ENV set with rbenv-vars. If we use fetch we can get an error on boot time that env key is missing.
Profits:
Cons:
And how do we set ENV on production apps?
EAT THAT ! ! ! https://gist.github.com/teamon/41f7b8697e1ea857cc64
One more thing agains builtin:
development:
some_key: "dummy value"
production:
some_key: "<%= ENV.fetch("SOME_KEY") %>"
Will result in exception on development since first the whole yml file is parsed and then only env specific vars are filtered so ENV#fetch
will be called anyway (hence the exception about missing ENV var)
/cc @monterail/dev
I'm on Figaro right now. ENV, Figaro.env, and required keys
@jandudulski Please make z PR explaining how to use Figaro with required keys properly.
Sure!
Which one should we use since rails 4.1? I started using in my private project secrets and it just works.
pros for secrets:
secret_key_base
database.yml
cons:
Rails.application.secrets
vs shorterFigaro.env
andENV
in FigaroAny thoughts?