Supporting multiple customers in a single rails app


#1

Here is what we are trying to do -

The idea is to allow different companies to access the same rails
application as their own personalized application. The only change in
the app per company is the title of the page, which is changed based on
the logged in user’s company through an attribute in the company table.
Internally it is one rails app, one database, security and access
control implemented based on models. The users are all “company”
specific. Currently at login, users choose the “company” from a
drop-down. Once logged in, we know who the user is, what company he
belongs to and can serve appropriate content. This works fine in testing
and I am looking for suggestions to make the login process easier.

Is there a way to eliminate the “choose company” at login? I looked
around and there seem to be a few options. But I am writing this to ask
the experts for suggestions. Certainly, there are scalability and
deployment issues that may impose an upper limit on any option – but as
a brain storming exercise, wanted to see what else is possible. We have
looked at one subdomain per company, creating company specific instances
of the app etc. but that might be an overkill for this app. We wanted to
try to stick with (as much as possible) a single database and a single
instance of the rails app.

We are playing around with the new routes in 1.2 to check if we can have
company specific urls (http://myapp.com/company1,
http://myapp.com/company2 etc.) to get around this. I will let you know
how our efforts proceed.

In the meantime, any suggestions, pointers from the experts?


#2

Well the first thing that came to my mind was the company-specific url,
though for me in terms of:

http://myapp/company1/login is the login page, but once logged in, the
site
acts as normal with no “company1/” prefix.

routes.rb:

map.company_login “:company/login”, :controller => ‘account’, :action =>
‘login’
(which will then fill in params[:company] with the given string, with
which
you can validate proper input).

Jason


#3

Thanks Jason.

That is exactly what we are trying with the new 1.2 routes. I will post
a summary once we know if that works.


#4

I ran a site for a few years (pre-rails) that had a different
environment for different companies. Everything ran off the same
codebase, and we did a subdomain lookup to populate local variables,
etc.

I wouldn’t do it this way with rails. I’d run separate web environment
for each customer, and probably use a single database.

I could maintain the consistency of the code throughout the different
apps by using a single capistrano deployment - i.e. creating multiple
identical copies. IMO the advantage would be in the scaleability.
Given that rails apps are so memory hungry, there’s every chance that
a successful site would need multiple instances spread across
multiple servers.

So, why not isolate the apps by company

This is just my opinion…I’m no expert…

To answer your question, though, Jason’s suggestion of a company
specific url makes sense. You’d need to wire the logout / login
functionally, accordingly.

Using subdomains would be easier. And might look more “professional”
from the clients’ point of view.


#5

On 27 Feb 2007, at 19:15, Chet wrote:

We are playing around with the new routes in 1.2 to check if we can
have
company specific urls (http://myapp.com/company1,
http://myapp.com/company2 etc.) to get around this. I will let you
know
how our efforts proceed.

In the meantime, any suggestions, pointers from the experts?

I would recommend the account_location plugin (script/plugin install
http://dev.rubyonrails.org/svn/rails/plugins/account_location/) and
use the subdomain as the identifier:
http://company1.myapp.com/
http://company2.myapp.com/
You’ll just need to put a wildcard a-record in your dns entries
(*.myapp.com) in order to forward all subdomain to your rails app. If
you want to test it locally (and want to use the subdomain, add a few
entries in your hosts (*nix) file or hosts in system32 on windows
that point to localhost).

It’s just so much more intuitive and gives a real feeling of custom
branding (a subjective feeling your customer gets because it’s the
very first thing in the url).

Best regards

Peter De Berdt