I think I lost you on my example of running the RAILS_ENV=production code locally & why it was safer without production config info checked in.
In my case I'm using a `.env` file and already have all the creds I need for local development i.e. stripe API token and AWS etc. They're all set for my own personal development account. When I want to profile the __behavior__ of a production app, it is super safe for me to use `RAILS_ENV=production` locally and be 100% confident that i'm not going to send out emails or blow away a production memcache because it's using the exact same __configuration__ as my development environment. When someone has all that info checked in as soon as they use `RAILS_ENV=production` then the app is a live loaded gun. As you mentioned this technique doesn't protect against the case where you ssh into your production box by accident and run a bad command. But neither does relying on someone to remember to run `RAILS_ENV=staging`, sure it might catch a slip up or two, but I guarantee if you rely on this, one day someone will forget that preface and tears will be made. It's also why we should potentially build in safe guards for the really dangerous components, like dropping databases. If you always have to remember to do something i.e. you always have to remember to preface every command with RAILS_ENV=staging, then it's insecure by default. If you're requiring the user to do the right thing 100% of the time, over the long run you'll always lose. Almost all major incidents and security breaches have a human component. My desire is to mitigate this as much as possible. > Furthor more (realy opinionated meaning, can be realy wrong) I think most of >your tickets came from RoR starters and not long term Rails users. These tickets came all types of customers. They came from some of our largest customers who have been running on the platform longer than I have worked there and new developers on free accounts. Every developer is capable of making a mistake. I'm not trying to pull rank here with my "i've been doing this for X long" i'm saying that i've seen A LOT of developers and apps make this mistake. This isn't an idea i'm pulling out of my butt here. At one point this was the largest ticket producer by a fair margin. After I introduced the article and added a warning, they've mostly disappeared I've heard basically no complaint or pushback of the concept from people who have done this. It's not so much an "opinion", that can be "really wrong", as it is a hypothesis that i've tested on hundreds-of-thousands/millions of rails apps and gotten a lot of positive confirmation on. This isn't an issue of "good" developers and "bad" developers. Here is a case of a huge outage caused by presumably someone who knows what they did yet made a mistake https://aws.amazon.com/message/41926/. The mitigation strategy is to make it so that doing the wrong thing is harder. Everyone regardless of skill or familiarity with a tool is a bad developer when they're tired or angry or drunk. So it's better to design for the "bad developer" case 100% of the time because it's a reality we all face. I built in code to explicitly protect people from dropping their production databases. Not because "only new developers do it" but because when anyone does it, regardless of how often...the results are catastrophic. Even if a problem is "easy to debug" if someone "knows what they're doing" it's not good enough if the problem could have been prevented via automation or code in the first place. Time is money and hours spent debugging when a issue could have been prevented entirely is, not ideal. > For instance you can't generate config file during deployment or do other >stuff. Tell me what you want to do on Heroku and I can tell you how it's possible. If you needed to generate files I would hook into the `rake assets:precompile` call. > For instance I have an env STAGING_DB... and PROD_DB ... . Within my staging >environment PROD_ is not set and my staging server has no connection to my >production systems. Great, this is what i'm talking about. Your staging or development server should not be __capable__ of accessing any sensitive 3rd party services tied to production. If you check them into your app, then they're accessible. You're doing what i'm advocating here. I don't care about how you store the information i.e. put it in an env var or some other configuration management toolchain, just whatever you do don't put all your secrets in your app and check them in to your source control and make them available to all running instances of your app. -- Richard Schneeman http://schneems.com On March 2, 2017 at 10:19:41 PM, Dieter ([email protected]) wrote: Furthor more (realy opinionated meaning, can be realy wrong) I think most of your tickets came from RoR starters and not long term Rails users. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
