Pros/cons of subdomains in web applications

An increasing number of web applications (most notably 37Signals' Basecamp) assign a subdomain to every user/account. I was wondering what the pros and cons are of such an approach. Is there a partic开发者_如何学编程ular reason for doing this or is this merely a cosmetic feature? Does this, for example, allow for better/easier scalability and improved security?

I think it may be related to the Same Origin Policy. If two users' member pages are on different subdomains, browsers will prevent scripts from one subdomain from accessing documents in another subdomain. So if Mallory registers a site (mallory.example.org) and puts a malicious script on it, that script won't be able to modify the DOM of Alice's site (alice.example.org). If they were using paths instead (example.org/mallory and example.org/alice), the SOP wouldn't work, and Mallory's script could do all sorts of bad things on Alice's page, like fake a login screen and post the passwords back to Mallory.

This SOP protection even works when both subdomains resolve to the same IP - as long as the host part of the URL is different, modern browsers will block cross-domain scripting attempts (and a few other potentially dangerous things).

Using a subdomain for each application solves the basic problem of knowing which application to use. This allows the user to open several applications at once in the same browser.

An added benefit is that by binding the login to the subdomain a user can be logged in as a different user in the different applications. There's no need to log out of app A to log in to app B. He can be logged in in both with a different login.

The benefit for scalability depends on your architecture. The more shared resources (a single database) the application has, the more difficult it is to separate the application. On the other hand, if you have a database for every application the versioning of the databases is much more trouble. I think most apps use a single database and virtual subdomains. A single base is easier to maintain (but more difficult to scale).

A negative point of using subdomains is that for SSL you need a wildcard certificate which costs more than a single-domain certificate.

We are doing this for the sole reason that people like seeing their brand. Conversion Support customers can pick a subdomain for the branding of their control panel and then customize it with their logo and colors.

Security isn't a factor since no one can put up scripts. It's more of an aesthetic feature.

I do want to mention that two subdomains can communicate if both pages have the document.domain JavaScript property set to the domain. For example:

 document.domain = 'example.com';  

This means the same origin policy is disabled for a.example.com and b.example.com to n.example.com as long as all subdomains have the property set.