This is still an OpenQuestion for me, so if you have any thought/concerns, be sure to add them to the list.
On the wild wild ‘net
After playing with rails behind your +7 Firewall of Impermeabilty for a while, you decide that you’re ready for prime time. You want to expose your rails app to the wild wild ‘net, but you don’t want it handed back to you an hour later a charred and smoking mass of broken dreams. So what should you do?
Here are a few suggestions (I don’t know how to do any of these yet myself, and I’m not at all convinced I’m not missing some obvious ones):
Switch to the “production” environment
While the development settings are useful while developing, exposing the innards of your app is not good for a site that’s serving real live people.
This has a number of advantages:
- In production mode users do not see the rescue page, and are not asked if they want to set breakpoints.
- In production mode, if routes can’t map the given path it renders your regular 404 page. No RoutingError is exposed to the user.
See Environments for more background and details on the matter.
Make sure to customize all the default pages
Even in the production environment, you want to avoid “leaking” information about your site to visitors.
Do a security check on your app
- Learn what tools Rails provides for securing your code. Read Securing your Rails
- Watch out for TheGoogleSpider
Don’t have unguarded GET methods to your controllers. - Watch out for SQL Injection
Use ? to build queries… - Watch out for HTML Injection
Use<%=h...
Check your configuration settings
- Make sure your FastCGI? timeout is high enough (http://weblog.rubyonrails.com/archives/2005/01/03/watch-for-huge-requests-on-default-fcgi)
- http://one.textdrive.com/pipermail/rails/2005-January/001409.html
Questions
- I’ve read that including a copy of Rails in your vendor folder is a good idea to protect against host upgrades that might break your app. Is this true, and if so, how is this done?
A: This is done by typing “rake rails:freeze:gems”.
category:Howto