Question

I’m contemplating a multi tenant application – shared database, shared schema. A tenant identifier (tenant key) associates every row with the right tenant.

What i’m not sure about is how to go about loading the tenant_id into some sort of global scope. How should this happen? I assume that I would parse the domain and then look up the tenant_id based on the domain.

My questions:

1. Where would the lookup happen in a rails application? In an initializer? Is there a better point to do this?
2. Once I have determined the tenant_id, what is the best way to persist it – a simple session_id?

Answer 1

I use a before filter for the controllers for this function.

You can also sub-class the controller class to DRY out duplicate code in the controllers.

Be careful to remember that access to a given tenant’s information needs to be authenticated on a per-user basis. You need to decide if a given user will have access to more than one tenant. Eg should user “joe” have access to tenants 1 and 2? Or should Joe need a per-tenant login?

The login’s authorization should control access to the tenant info. Don’t rely on the domain name to grant authorization.

Re: where to persist the tenant_id? Store in the session. If access to the session is expensive (stored in DBMS), then make an in-memory copy as an instance variable during the controller startup. Google for how user_ids are often stored.

You also should determine the user experience for if/when a user wants to access a different tenant.

Added To see which welcome screen to load before the user has logged in, looking at the subdomain name is a good choice. To see which subdomain the incoming request used, parse request.fullpath() Docs. Do this in a controller filter.

Since the authorization comes from the user_id, remember to test the case where joe logs in at tenant1.app.com but only has access to tenant2.app.com

Bonus answer Looking for a templating system that will enable your customers to have full control over their tenancy’s user interface? Check out Liquid templates. I was very successful in using them to enable my customers to have full control over their look and feel in a safe way.

Re additional questions in comment

• See superuser for configuring the web server. The config is web server-specific.
• If you want the welcome screen to not be generic, then you must know from the request url how to customize it. Tenant-specific subdomain is the nicest. If no subdomain, then show the generic welcome–when the person logs in you can determine the tenant and how to customize.

Re helper–if you mean a view helper, then I would not recommend it as the primary place where the tenant is determined. Make the @user and @tenant be light-weight models that you look up once and then retrieve from the session during additional requests for the same session. The models will be used by the controllers and, perhaps, passed to the models. The View layer will also be able to see them and use them as necessary.

If the UI may look/will look completely different for the different tenants, then add a “tenant-display” layer in addition to the view. Eg have the view gather the instance variables, find the right Liquid template, then express the view via the template.

You don’t want the view to be computing “if tenant_a then x else y”