I've successfully managed to set up an app using my developer account - it is currently making use of Ruby on Rails 4.2.beta2, ejholmes most excellent gem restforce and the very helpful tutorial and sample code from Bruno fagundez. All of which are excellent resources I'd highly recommend to anyone looking to devise a quick, easy and clean salesforce compatible app (sorry had to strip the links as I have <10 rep here!).

Before I switch things to our production salesforce instance for further setup and testing I wanted to pause to consider security in greater depth.

In all likelihood I will be deploying to a service such a heroku or ninefold (as Sean Devine made such a good sales-pitch for it this week on this week's 5by5 rails podcast!). So could someone help me thing through exactly where and how I should go about storing thin order to secure my authentication credentials.

The 'geeky martin' tutorial, has you write them straight into a omniauth.rb file stored in initializers, his sample code does it slightly differently by abstracting from the config/initilizers/omniauth.rb file as so:

provider :salesforce, Rails.application.config.salesforce_app_id, Rails.application.config.salesforce_app_secret and then creating the variables in the /config/application.rb by:

config.salesforce_app_id = 'YOUR_SALESFORCE_APP_ID' config.salesforce_app_secret = 'YOUR_SALESFORCE_APP_SECRET'

This works currently, but how secure are these variables in the grand scheme of things? If I assume i can keep my ninefold or heroku instance secure, what are the threats and vulnerabilities of storing things in the /config/* and would anyone be able to publicly get at these when in production?

I remember from fiddling with the databasedotcom gem, they used to run things from a salesforce.yml file. I've been presuming that is more secure (if for no other reason than I could add it to my gitignore and so never have to worry about publicly committing my authentication secrets!!). I could imagine this might also have the benefit of me splitting out test, production and development variables so I could check things work on my developer account without blowing all our client details away with an errant destroy command!

I've noticed too this mysterious secrets.yml file (seemingly new to rails 4.1 this seems like a good candidate for putting my app authentication variables inside and loading them in as environmental variables (which if I understand correctly will mean they're 'as-safe-as-my-server-instance', rather than floating around as potentially more accessible app variables..?)

And then... I'm wondering if there's any value in attempting to further secure these details with encryption (bcrypt)... if I should hash and salt passwords... why not and wouldn't it work with these?

So in short, I'm trying to think through how best to secure authentication details to secure them both to reduce risk from potential attackers and my own incompetence by accidentally pushing authentication variables to github.

Any thoughts on best practice?

1 Answer 1


I have used figaro gem for development where it stores all the environment variables in application.yml. The common mistakes that I have made was pushing secure variables to your version control system like git and github. So you have to make sure you ignore these files when you are doing git push to any public repo. Gems like figaro auto populates yml files to gitignore file. My security seems to pass when I deploy and check the status with services like codeclimate.

  • This is a really interesting thought, I might give this a try - I'm also terrified of leaking my secret token via git!
    – Huw
    Mar 2, 2015 at 12:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .