search

andreapavoni / nova

An attempt to port/rebuild Spree, an open source e-commerce solution, with Elixir and Phoenix.
129 stars 11 forks source link

Remove `secret_key_base` #3

Closed juandazapata closed 9 years ago

juandazapata commented 9 years ago

This is too sensitive to be committed to the repo. It should be handled in an env var, or as part of a setup task. An incautious user could just left this value unchanged, accidentally exposing itself to a vulnerability. This should be unique per each installation.

https://github.com/nebulab/gcommerce/blob/master/config/config.exs#L12

andreapavoni commented 9 years ago

Hi @juandazapata , thank you for pointing this out :-)

You're right, in normal conditions this should be a serious security issue, however, it isn't when it comes to production environments, because config/prod.exs loads config/prod.secret.exs by default, which (actually) isn't tracked by the version control. You can get rid of it by editing config/prod.exs in this way:

config :nova, Nova.Repo,
  adapter: Ecto.Adapters.Postgres,
  # username: System.get_env("NOVA_DB_USER"),
  # password: System.get_env("NOVA_DB_PASSWORD"),
  # database: "nova_prod",
  url: {:system, "DATABASE_URL"}, # For Heroku deploys
  pool_size: 20

config :nova, Nova.Endpoint,
  # [...]
  secret_key_base: {:system, "NOVA_SECRET_KEY_BASE"}

which means:

  1. You can track this file to git, without sharing prod secrets
  2. You don't have to worry about dev and test secrets

This is also the suggested approach from the Phoenix guides. With this approach, we can safely use config/prod.exs without concerns :-)

As a side note, my first attempt was to integrate dotenv_elixir to easily keep all envs in a dotfile, but it doesn't work inside Mix; see this discussion for more details.