views:

279

answers:

1

Fogbugz-on-demand, 37 signals, and PB-Wiki all use sub-domains with custom url's for each group of users to access their login page. So it doesn't even seem possible for a user using those services to login to a generc login (that any user of the service could log into.)

At first I thought this was a terrible design flaw, but now I think this is a really good idea because of: 1) Additional security, it may not be much, but you now need 3 pieces of info: 1 sub-domain url, 2 login, 3 password

2) You can let the same login log into different accounts by the subdomain url.

3) This lends itself to more isolation, load balancing, and easy deployment since you can have the subdomains running under different servers in more isolation from each other.

4) You can gradually roll out changes to a certain set of sub-domains that are marked as BETA users before deploying them to all users.

Are sub-domain based logins for web applications the future? Are there pitfalls with this design approach I'm not seeing? Is it too confusing for non-programmer users to understand the sub-domain concept?

+1  A: 

We went with a triple-element login instead. We ask for the username, password, and client-id. Same concept as the sub domains but there's a common login URL. That works fine too. However, I do see an advantage in the sub-domain process, you can brand the login page because you know the requested client. In our approach we can't brand the login page since we don't know the client until you submit the login page.

WaldenL