Permalink
Browse files

Added a shared section to config/secrets.yml that will be loaded for …

…all environments
  • Loading branch information...
dhh committed May 21, 2016
1 parent 85ee483 commit e530534265d2c32b5c5f772e81cb9002dcf5e9cf
View
@@ -1,2 +1,7 @@
## Rails 5.1.0.alpha ##
* Added a shared section to config/secrets.yml that will be loaded for all environments.
*DHH*
Please check [5-0-stable](https://github.com/rails/rails/blob/5-0-stable/railties/CHANGELOG.md) for previous changes.
@@ -385,11 +385,16 @@ def config=(configuration) #:nodoc:
def secrets
@secrets ||= begin
secrets = ActiveSupport::OrderedOptions.new
yaml = config.paths["config/secrets"].first
yaml = config.paths["config/secrets"].first
if File.exist?(yaml)
require "erb"
all_secrets = YAML.load(ERB.new(IO.read(yaml)).result) || {}
env_secrets = all_secrets[Rails.env]
all_secrets = YAML.load(ERB.new(IO.read(yaml)).result) || {}
shared_secrets = all_secrets['shared']
env_secrets = all_secrets[Rails.env]
secrets.merge!(shared_secrets.symbolize_keys) if shared_secrets
secrets.merge!(env_secrets.symbolize_keys) if env_secrets
end
@@ -10,6 +10,13 @@
# Make sure the secrets in this file are kept private
# if you're sharing your code publicly.
# Shared secrets are available across all environments.
shared:
api_key: 123
# Environmental secrets are only available for that specific environment.
development:
secret_key_base: <%= app_secret %>
@@ -18,5 +25,6 @@ test:
# Do not keep production secrets in the repository,
# instead read values from the environment.
production:
secret_key_base: <%%= ENV["SECRET_KEY_BASE"] %>
@@ -555,6 +555,31 @@ def index
assert_equal 'myamazonsecretaccesskey', app.secrets.aws_secret_access_key
end
test "shared secrets saved in config/secrets.yml are loaded in app secrets" do
app_file 'config/secrets.yml', <<-YAML
shared:
api_key: 3b7cd727
YAML
app 'development'
assert_equal '3b7cd727', app.secrets.api_key
end
test "shared secrets will yield to environment specific secrets" do
app_file 'config/secrets.yml', <<-YAML
shared:
api_key: 3b7cd727
development:
api_key: abc12345
YAML
app 'development'
assert_equal 'abc12345', app.secrets.api_key
end
test "blank config/secrets.yml does not crash the loading process" do
app_file 'config/secrets.yml', <<-YAML
YAML

8 comments on commit e530534

@rafaelfranca

This comment has been minimized.

Show comment
Hide comment
@rafaelfranca
Member

rafaelfranca replied May 21, 2016

👍

@rafaelfranca

This comment has been minimized.

Show comment
Hide comment
@rafaelfranca

rafaelfranca May 21, 2016

Member

Well, is not this reimplementing YAML's shared keys?

default: &default
    api_key: 3b7cd727

development:
  <<: *default

This is what we do in database.yml

Member

rafaelfranca replied May 21, 2016

Well, is not this reimplementing YAML's shared keys?

default: &default
    api_key: 3b7cd727

development:
  <<: *default

This is what we do in database.yml

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh May 21, 2016

Member

I hate that YAML syntax. It's completely obtuse and undiscoverable. We should IMO implement shared in database.yml as well.

Member

dhh replied May 21, 2016

I hate that YAML syntax. It's completely obtuse and undiscoverable. We should IMO implement shared in database.yml as well.

@nynhex

This comment has been minimized.

Show comment
Hide comment
@nynhex

nynhex May 21, 2016

I like the idea of having shared resources between environments in both database.yml and secrets.yml. Comes in handy. 👍

nynhex replied May 21, 2016

I like the idea of having shared resources between environments in both database.yml and secrets.yml. Comes in handy. 👍

@rafaelfranca

This comment has been minimized.

Show comment
Hide comment
@rafaelfranca

rafaelfranca May 21, 2016

Member

at this point we would create our own YAML language and I don't think this is a good idea. This means that every single external service that share the yaml configuration will have to implement the same parser as ours. With the YAML shared keys every application in any language would have the same values for the secrets without having to implement the same logic than Rails.

Member

rafaelfranca replied May 21, 2016

at this point we would create our own YAML language and I don't think this is a good idea. This means that every single external service that share the yaml configuration will have to implement the same parser as ours. With the YAML shared keys every application in any language would have the same values for the secrets without having to implement the same logic than Rails.

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh May 21, 2016

Member

If you need to share YAML between non-Rails processes, then don't use this feature. That's by very far and away the minority case, and it's still completely possible to do it like that. I don't mind in the least that you have to do a bit of handy work yourself if you're integrating things like that.

Member

dhh replied May 21, 2016

If you need to share YAML between non-Rails processes, then don't use this feature. That's by very far and away the minority case, and it's still completely possible to do it like that. I don't mind in the least that you have to do a bit of handy work yourself if you're integrating things like that.

@rafaelfranca

This comment has been minimized.

Show comment
Hide comment
@rafaelfranca
Member

rafaelfranca replied May 21, 2016

👍

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh May 21, 2016

Member

One of the advantages of using a shared block like this is that you then don't have to declare a new environmental block for envs that only use shared secrets and nothing env specific.

Member

dhh replied May 21, 2016

One of the advantages of using a shared block like this is that you then don't have to declare a new environmental block for envs that only use shared secrets and nothing env specific.

Please sign in to comment.