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?
on 2007-02-27 19:15
on 2007-02-27 20:18
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
on 2007-02-27 20:50
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.
on 2007-02-27 21:10
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.
on 2007-02-27 22:58
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/accou...) 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