I was thinking about application configuration and how to handle it in Rails, so I did a little Googling. I found Railscast #85, which addresses the issue. I was able to use the information provided by the author, Ryan Bates, to quickly whip up a configuration file containing information specific to my application.
In the process, however, I noticed that some issues were not addressed. They are:
- Storing some types of data, such as passwords or private keys, in configuration files that are under version control might not be a good idea. Mr. Bates acknowledged this around the two minute mark.
- It’s generally considered a good practice to store sensitive information outside the document root. That way, if the raw code is served (instead of the rendered HTML) via a configuration error or security hole, the sensitive information won’t be exposed.
The first option for storing configuration data that is presented is to simply use constants stored in environment.rb. After that, he moves on to the more sophisticated option of using a YAML file stored in the config directory and loading it via a call to YAML.file_load() in either environment.rb or an initializer. For nonsensitive needs, this is fine. However, both options fail to address the concerns listed above. The YAML file is still likely to end up in version control, and it’s still not outside the root. Any good version control system should allow you to ignore a file, of course, but accidents can still happen. I’m also a little surprised that he raised the issue and then ignored it.
Keeping documents outside the document root is a little more interesting, and not something that I’ve looked into much with respect to Rails. I found a blog posting that uses Nginx configuration info to fake it, but it only works with that specific server. I’m going to have to poke around a bit more; my initial round of Googling turned up nothing.
There are other ways to handle this, such as placing the values in a database table. I ran into rails-settings, a gem created for this purpose. Using the database avoids the version control issue (assuming that you don’t use a migration to initialize the table), but you can’t use it to store information needed to connect to the database, obviously.
If you’re looking for options for storing application config data, watch the railscast. Keep these two issues in mind while you do, though.
