With a multi-db or multi-schema approach, you only deal with the multi-tenancy-aspect in a few specific spots in your app (Jerod Santo recently wrote an excellent post on implementing a multi-schema strategy). Compared to the previous two strategies, a shared database strategy has the downside that the ‘multi-tenancy’-logic is something you need to actively be aware of and manage in almost every part of your app.
For various other reasons we opted for a shared database strategy. However, for us the prospect of dealing with the multi-tenancy-logic throughout our app, was not appealing. Worse, we run the risk of accidently exposing content of one tenant to another one, if we mismanage this logic. While researching this topic I noticed there are no real ready made solutions available that get you on your way, Ryan Sonnek wrote his ‘multitenant’ gem and Mark Connel did the same. Neither of these solution seemed “finished” to us. So, we wrote our own implementation.
A shared database strategy manages the multi-tenancy-logic through Rails associations. A tenant is represented by an object, for example an Account
. All other objects are associated with a tenant: belongs_to :account
. Each request starts with finding the @current_account
. After that, each find is scoped through the tenant object: current_account.projects.all
. This has to be remembered everywhere: in model method declarations and in controller actions. Otherwise, you’re exposing content of other tenants.
In addition, you have to actively babysit other parts of your app: validates_uniqueness_of
requires you to scope it to the current tenant. You also have to protect agaist all sorts of form-injections that could allow one tenant to gain access or temper with the content of another tenant (see Paul Gallaghers presentation for more on these dangers).
I wanted to implement all the concerns above in an easy to manage, out of the way fashion. We should be able to add a single declaration to our model and that should implement:
- scoping all searches to the current
Account
- scoping the uniqueness validator to the current
Account
- protecting against various nastiness trying to circumvent the scoping.
The result is acts_as_tenant
(github), a rails gem that will add multi tenancy using a shared database to your rails app in an out-of-your way fashion.
In the README, you will find more information on using acts_as_tenant
in your projects, so we’ll give you a high-level overview here. Let’s suppose that you have an app to which you want to add multi tenancy, tenants are represented by the Account
model and Project
is one of the models that should be scoped by tenant:
class Addaccounttoproject < ActiveRecord::Migration
def change
add_column :projects, :account_id, :integer
end
end
class Project < ActiveRecord::Base
acts_as_tenant(:account)
validates_uniqueness_to_tenant :name
end
What does adding these two methods accomplish:
- it ensures every search on the project model will be scoped to the current tenant,
- it adds validation for every association confirming the associated object does indeed belong to the current tenant,
- it validates the uniqueness of `:name` to the current tenant,
- it implements a bunch of safeguards preventing all kinds of nastiness from exposing other tenants data (mainly form-injection attacks).
Of course, all the above assumes `acts_as_tenant` actually knows who the current tenant is. Two strategies are implemented to help with this.
Using the subdomain to workout the current tenant
class ApplicationController < ActionController::Base
set_current_tenant_by_subdomain(:account, :subdomain)
end
Adding the above method to your `application_controller` tells `acts_as_tenant`:
- the current tenant should be found based on the subdomain (e.g. account1.myappdomain.com),
- tenants are represented by the `Account`-model and
- the `Account` model has a column named `subdomain` that should be used the lookup the current account, using the current subdomain.
Passing the current account to acts_as_tenant yourself
class ApplicationController < ActionController::Base
current_account = Account.method_to_find_the_current_account
set_current_tenant_to(current_account)
end
`Acts_as_tenant` also adds a handy helper to your controllers `current_tenant`, containing the current tenant object.
- scoping of models *only* works if `acts_as_tenant` has a current_tenant available. If you do not set one by one of the methods described above, *no scope* will be applied!
- for validating uniqueness within a tenant scope you must use the `validates_uniqueness_to_tenant`method. This method takes all the options the regular `validates_uniqueness_of` method takes.
- it is probably best to add the `acts_as_tenant` declaration after any other `default_scope` declarations you add to a model (I am not exactly sure how rails 3 handles the chaining. If someone can enlighten me, thanks!).
We have been testing acts_as_tenant within Roll Call during recent weeks and it seems to be behaving well. Having said that, we welcome any feedback. This is my first real attempt at a plugin and the possibility of various improvements is almost a given.