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 and
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. On Strongspace, they
have 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 it redirects to www.strongspace.com. Finally, on
Basecamp, all the actual accounts are on one of their other domains,
such as clientsection.com and updatelog.com, and the signup process
takes you to 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
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.
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 and
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. On Strongspace, they
have 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 it redirects to www.strongspace.com. Finally, on
Basecamp, all the actual accounts are on one of their other domains,
such as clientsection.com and updatelog.com, and the signup process
takes you to 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