# Differentiating between normal site content and accounts wit **URL:** \ **Category:** Rails\ **Created:** [February 4, 2006, 7:41am UTC](https://www.ruby-forum.com/t/differentiating-between-normal-site-content-and-accounts-wit/100925 "2006-02-04T07:41:32Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Toby\_Sterrett](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/d9b06d/32.png) [@Toby\_Sterrett](https://www.ruby-forum.com/u/Toby_Sterrett)\ **Post date:** [February 4, 2006, 7:41am UTC](https://www.ruby-forum.com/t/differentiating-between-normal-site-content-and-accounts-wit/100925/1 "2006-02-04T07:41:32Z")
I’m using the subdomains as accounts method fine on a project, but I’m wondering what is the best way to differentiate between account subdomains to access the app using an account, and [www.domain.com](http://www.domain.com) and [domain.com](http://domain.com) in order to show normal site content. I’ve noticed that on Backpack, it seems that when you leave the information pages and start using the app, such as signing up or logging in, takes you to [123.backpackit.com](http://123.backpackit.com). On Strongspace, they have [www.strongspace.com/\*](http://www.strongspace.com/*) go to all the informational pages, as well as signup. I have, however, noticed that if you try to enter [strongspace.com](http://strongspace.com) it redirects to [www.strongspace.com](http://www.strongspace.com). Finally, on Basecamp, all the actual accounts are on one of their other domains, such as [clientsection.com](http://clientsection.com) and [updatelog.com](http://updatelog.com), and the signup process takes you to [secure.basecamphq.com](http://secure.basecamphq.com). I’d prefer to use one domain like Strongspace does. So, what would be the recommended way for handling this? Is it handled at the server level, or in Rails? Thanks for your help. Toby ---
**Author:** ![Toby\_Sterrett](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/d9b06d/32.png) [@Toby\_Sterrett](https://www.ruby-forum.com/u/Toby_Sterrett)\ **Post date:** [February 4, 2006, 9:15am UTC](https://www.ruby-forum.com/t/differentiating-between-normal-site-content-and-accounts-wit/100925/2 "2006-02-04T09:15:22Z")
Hey Toby. If I had this to do before Rails, which for me meant Apache+mod\_perl, I’v set it up like this to great result: A proxy server doing http(s) to client serving static content, and proxying dynamic content (via URL matching) to a server on another port number. This system can live on a single box and be rapidly extended to multple machine configurations with some boxes serving static and handing dynamic requests back to another group of script executing boxes. The big win from this system is that the static+proxy front ends can be running a very lightweight Apache configuration and run a very large number of connections per box compared to the heavy memory footprint of the mod\_perl systems. However, now that I’ve been introduced to Lighhtpd + Rails, I think I’d leave out the proxy and serve everything from a single web server. If site gets busy, I would load balance into a farm of identically configured machines, sharing a clustered database. Lighhtpd’s ability to serve connections so inexpensively that each box can handle enough connections to balance with the processor requirements of the dynamic requests. With that in mind (whew), Lighhtpd can be configured to serve hits to all of the domains you want to serve from. The Rails application can parse and store the domain at session creation, and use that as required in the dynamic stuff. Knowing how extensible Rails is, I’d be surprised if it was difficult at all to get Rails to use that domain a an extra criterion in selecting which views to use, so that you could layout views so that a request to: http:///www.domain.com/controller/action would result in: app/views/domain/controller/action.rhtml to be rendered. With that in place, you could run the same application, on boxes serving several different domains, where all servers are completely identical. – – Tom M. ---
**Author:** ![Toby\_Sterrett](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/d9b06d/32.png) [@Toby\_Sterrett](https://www.ruby-forum.com/u/Toby_Sterrett)\ **Post date:** [February 5, 2006, 4:59pm UTC](https://www.ruby-forum.com/t/differentiating-between-normal-site-content-and-accounts-wit/100925/3 "2006-02-05T16:59:13Z")
I’m toying with these ideas myself. I had the thought that it might be kind of nice to have different rails apps and different databases for each of the main domains. I think I will eventually ditch this idea, but it’s a thought. My guess is that much of this is done in the server configuration (lighttpd.conf) and the rails app is designed to just run with whatever it gets. In other words, if the signup page is called for, then the rails app assumes that the server did it’s job in making sure that’s what the user wants. The server’s job is to forward to static pages when a non-app page is called for. It’s very early in my exploration of this, though. I’ll be following this thread. Jake Toby Sterrett wrote: > I’m using the subdomains as accounts method fine on a project, but > I’m wondering what is the best way to differentiate between account > subdomains to access the app using an account, and [www.domain.com](http://www.domain.com) and > [domain.com](http://domain.com) in order to show normal site content. > > I’ve noticed that on Backpack, it seems that when you leave the > information pages and start using the app, such as signing up or > logging in, takes you to [123.backpackit.com](http://123.backpackit.com). On Strongspace, they > have [www.strongspace.com/\*](http://www.strongspace.com/*) go to all the informational pages, as well > as signup. I have, however, noticed that if you try to enter > [strongspace.com](http://strongspace.com) it redirects to [www.strongspace.com](http://www.strongspace.com). Finally, on > Basecamp, all the actual accounts are on one of their other domains, > such as [clientsection.com](http://clientsection.com) and [updatelog.com](http://updatelog.com), and the signup process > takes you to [secure.basecamphq.com](http://secure.basecamphq.com). I’d prefer to use one domain like > Strongspace does. > > So, what would be the recommended way for handling this? Is it > handled at the server level, or in Rails? > > Thanks for your help. > > Toby