We are midway through a large project at the moment. It’s our biggest Ruby on Rails project for a client to date and consists of a front end and an administration area based on our DATA CARTON technology. Early on we faced several organisational conflicts between these two opposing forces.
Our DATA CARTON framework was adverse to settling in directly with its public facing companion, our models (while obviously the same) were actually required to be configured in subtly different ways, and with multiple developers and designers working together, we decided to split them into two applications both pointing at the same database.
While these logical units promised simpler security, cleaner directory structures and more streamlined development, we hadn’t tried this before but decided to just forge ahead anyway. These are the problems we encountered and how we solved them:
1. Logins
Our front end is community-based and all users of the system from newsletter subscribers to administrators share a users table. The first thing we did after pointing our database.yml file at the same database was to try logging in to both applications with the test user we had created. After only a 50% success rate, we traced the problem to our password encryption method that uses a mixture of the user’s password choice, a salt and an application specific key string. Different keys are going to result in different hashes and incompatible authentication routines in the applications. A quick switch to using identical strings and we were successfully creating users and logging-in in all possible combinations.
def self.encrypt(pass, salt)
finalString = pass + 'somekey' + salt
Digest::SHA1.hexdigest(finalString)
end2. Sessions
Our next thought was ’sharing sessions would be nice’. Linking administrators directly to the backend from their frontend toolbar without having to login again, passing secret messages back and forth, that sort of thing. Rails offers cookie-only sessions or database based ones. Using the more data-sensitive one is a simple matter of uncommenting these lines from the application’s environment.rb:
config.action_controller.session_store =
:active_record_storeThen in the same file (environment.rb) you’ll find your session security key and secret:
config.action_controller.session = {
:session_key => 'some_secret_key',
:secret => 'some_secret_hash'
}Rails generates both of these automatically when creating your application. They are sent with every non-GET request (i.e. PUT, POST, DELETE) to verify your session and protect against cross-site forgery (there’s actually a few fiddly issues with getting in-place edits working while using this method, but I’ll save that for another post).
The important thing here is to again make sure all keys and secrets are consistent across both applications. So pick one and copy it across. Once you’ve synchronised your environment.rb session settings, you’ll need to uncomment and duplicate your session secret from the top of controllers\application.rb too. Now you’re sharing sessions!
protect_from_forgery :secret => 'some_secret_hash'
3. Subdomains
We quickly realised that our session sharing was not going to be as smooth as first anticipated, as we typically run our client’s backends on an admin subdomain (i.e. http://admin.abcdefg.com) and as cookies don’t take kindly to being requested by subdomains that haven’t sent them, we still didn’t have our single login functionality.
After much brainstorming and hunting around, we eventually found this genius configuration option that (notice the all important ‘.’ prefix) makes the cookie available to all subdomains on a domain. Finally we had truly shared sessions.
ActionController::CgiRequest::DEFAULT_SESSION_OPTIONS.
update( :session_domain => '.abcdefg.com')4. Migrations / Models / Helpers / Deployment
The remaining issues are ones we are still facing and gradually solving. These tend to be less of a technical matter and more of an organisational one. We’re quickly establishing rules for how we order the migration files, share some models while keeping the security sensitive ones separate, bundling all of our helpers up into libraries and unifying deployment. We’re not quite there yet, but I’ll be sure to share our assumptions and solutions soon.
This article was first published on www.russellquinn.com in January 2008.
