I am an active member of Ruby community. I have been consistently contributing to Ruby on Rails for a number of years and now am one of the top 30 contributors to Ruby on Rails. I also help as co-editor for the This week in Rails newsletter. Besides Ruby on Rails I have also contributed to many other notable open source projects including Sinatra, Devise and Rake. I am a seasoned speaker an have spoken at many conferences around the world including Gogaruco in San Francisco, RedDotRubyConf in Singapore, RubyConfIndia in Goa, India MadisonPlusRuby in Madison, Wisconsin, RubyConfBrazil in Suo Paulo, Brazil, and RubyConf Philippines in Manilla, Philippines. I am organizer of Deccan Ruby Conference and used to run RubyIndia Podcast. During my early days of open source as part of "Google summer of code" I contributed to the krypt-project project. Later I helped mentor in the JRuby and currently mentor in the Ruby on Rails organization for Google summer of code. When not working on Ruby, I am mostly working on Reactjs. I have authored the book Building Modern Web Applications with React.js which is published by PACKT. I have produced a number of screencasts on the topic of Learn React.js.
1 minute read
Rails 5.1 introduced the use of secrets
for storing encrypted secrets in source control.
It also allowed
plain environment specific settings storage
making usage of secrets.yml.
And access this configuration using Rails.application.secrets
Rails made use of SECRET_BASE_KEY for these encrypting the stored secrets.
The combination of config/secrets.yml, config/secrets.yml.enc and SECRET_BASE_KEY was confusing.
It was not clear what one should be putting in these secrets, encrypted secrets and how SECRET_BASE_KEY is related to the setup in general.
To overcome this confusion secrets were replaced with credentials,
and limited its usage to only encrypted credentials/
Using secrets is now deprecated.
Using config_for as a replacement for secrets.yml
Since secrets.yml is now deprecated we need a new way to store the configuration above.
We can make use of existing functionality config_for
to achieve the same desired effects.
First, we break down and move the configuration to a new config file.
Since the configuration is about mailer, lets store the config config/mailer.yml
We need to then load this configuration.
After loading this configuration we can start using the mailer configuration on Rails.configuration.mailer
Using config_for helps us break down configuration into separate namespaced files,
relative to what they useful for: mailer, host, exception_notifier and more.