You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be cool if this gem did some of these things:
Aliased Rails.application.secrets to Settings.secrets
Shimmed the secrets.yml functionality in for Rails < 4.1
Allowed you to have a secrets.local.yml or config/secrets/production.yml that behave the same way as the existing conventions do for non-secrets files
I think this gem is a better overall solution to managing configuration, but if Rails is making this a thing, it would make sense to go along with it and make this gem work nicely with the new stuff.
Rails 5 gets away from using secrets and now has a credentials file. It would be cool to have similar functionality built into this gem since it provides a much more flexible way of managing environment settings.
I think we could add alias Rails.application.secrets to Settings.secrets if anybody is interested in this. However, I would keep the way secrets.yml work meaning with environments groups.
@smtlaissezfaire I would welcome a PR fixing this. Would like to have a look? I no longer work with Rails for few years now so it would be hard for me to get back to it...
Just sharing my workaround to work with Rails.application.credentials. Not sure if this the best solution, but this monkey patch works for me to utilize Setting and Rails secret management.
# config/initializers/config.rbmoduleConfigdefself.load_files(*sources)config=Options.new# add settings sources[sources].flatten.compact.eachdo |source|
config.add_source!(source)endconfig.add_source!(Sources::EnvSource.new(ENV))ifConfig.use_envload_credentials(config)# call Settings overrideconfig.load!configend# override with crendentialsdefself.load_credentials(config)ifRails.env.production? || Rails.env.staging?# Load and replace secret from credentialsconfig.add_source!(Rails.application.credentials.to_h)endendendConfig.setupdo |config|
# your configend
@noxasch I like the idea of merging the Rails credentials into the Settings exported by config. I think that's probably the most ergonomic workflow: all configuration lives in Settings, but you can still use encrypted credentials (they just get merged in)
I could use help understanding why the monkey patch is necessary, though. If, in an initializer, you just
@cjlarose Yup correct, you can also do that. As for me I want to load the Settings when the config gem is being initialize. So everything related to Settings work as if it is part of the gem. Probably better if the gem allow us to include a block before the config first load though.
Yeah, that makes sense. In a non-Rails application, config doesn't do anything automatically and the user has the opportunity to customize everything that gets merged into Settings (specific YAML files, hard-coded Hashes, environment variables, etc), but the Rails integration makes some assumptions and performs the first load before the user has the chance to customize anything. That's a separate issue. In the meantime, I'm open to a PR that adds a new (off by default) setting Config.use_rails_credentials that would basically just do what @noxasch 's patch does.
I think we might have to use something like Rails.application.credentials.to_h.deep_stringify_keys though in order for merging to work correctly with other config sources.
Activity
Darkside73 commentedon Aug 18, 2014
Will be great
pkuczynski commentedon Jun 28, 2019
@rdubya would you like to have a look at this one?
rdubya commentedon Jul 1, 2019
Rails 5 gets away from using secrets and now has a
credentialsfile. It would be cool to have similar functionality built into this gem since it provides a much more flexible way of managing environment settings.pkuczynski commentedon Aug 6, 2019
I think we could add alias
Rails.application.secretstoSettings.secretsif anybody is interested in this. However, I would keep the waysecrets.ymlwork meaning with environments groups.@smith @Darkside73 are you still interested in this?
smtlaissezfaire commentedon Oct 23, 2023
FYI This bug caused me so much pain...
the config gem eager loads credentials, causing any overrides to not be respected in config/application.rb
pkuczynski commentedon Oct 24, 2023
@smtlaissezfaire I would welcome a PR fixing this. Would like to have a look? I no longer work with Rails for few years now so it would be hard for me to get back to it...
noxasch commentedon Feb 12, 2024
Just sharing my workaround to work with
Rails.application.credentials. Not sure if this the best solution, but this monkey patch works for me to utilize Setting and Rails secret management.cjlarose commentedon Feb 12, 2024
@noxasch I like the idea of merging the Rails credentials into the
Settingsexported byconfig. I think that's probably the most ergonomic workflow: all configuration lives inSettings, but you can still use encrypted credentials (they just get merged in)I could use help understanding why the monkey patch is necessary, though. If, in an initializer, you just
Does that work? Or does it not have the opportunity to pick up the credentials correctly?
[-]Integration with secrets.yml[/-][+]Integration with encrypted Rails credentials[/+]noxasch commentedon Feb 13, 2024
@cjlarose Yup correct, you can also do that. As for me I want to load the
Settingswhen the config gem is being initialize. So everything related toSettingswork as if it is part of the gem. Probably better if the gem allow us to include a block before the config first load though.cjlarose commentedon Feb 13, 2024
Yeah, that makes sense. In a non-Rails application,
configdoesn't do anything automatically and the user has the opportunity to customize everything that gets merged intoSettings(specific YAML files, hard-codedHashes, environment variables, etc), but the Rails integration makes some assumptions and performs the first load before the user has the chance to customize anything. That's a separate issue. In the meantime, I'm open to a PR that adds a new (off by default) settingConfig.use_rails_credentialsthat would basically just do what @noxasch 's patch does.I think we might have to use something like
Rails.application.credentials.to_h.deep_stringify_keysthough in order for merging to work correctly with other config sources.pkuczynski commentedon Feb 18, 2024
@noxasch would you like to fire up a PR for this change?
noxasch commentedon Feb 19, 2024
Sure I can work on a PR for this @pkuczynski
dominh commentedon Apr 22, 2024
Is any help still needed?
I'd like to have it in my project too and I see needs help badge, but I'm not getting what help is still needed.