Skip to content

better*practices: The Case for Account-based Subdomains

One of Web 2.0’s darling applications, [Basecamp][1], uses account-based subdomains to provide an easy-to-remember, personalized URL for each account. Aside from the above benefits, I’ve discovered another helpful feature enabled by such a practice: password management.

Most modern browsers provide some way to save site passwords, whether by hooking into the OS capabilities or by rolling their own. Both types, however, key the saved username/password combination on the domain name of the site you save it from, rather than the full URL. This makes sense because it enables you to go to any page on the domain that requires login and have the form automagically filled for you.

But what happens in the following case? I check two Gmail accounts, one that is personal and another that is a shared account for a workgroup. As a result, my browser only remembers the last login for Google Mail, and I find myself having to look up the other one, or at the very least type in the other username and hope the browser finds the password.

If, on the other hand, Google Mail used domains such as __myaccount.gmail.com__ and __bizaccount.gmail.com__, I could maintain multiple logins, _even at the same time_ and my browser would easily remember both.

A long, long time ago I used 3 different passwords for just about everything. These days, almost all of my passwords are plucked straight from [`apg`][2], a command-line password generation utility, and remembering every single one of them is damn near impossible. Sure, the passwords I use every day come to me easily, but what about the dozens that I don’t?

It’s really easy to implement something like this these days… in Ruby on Rails, the code for [using subdomains as account keys][3] looks like this:

attr_writer :account
attr_reader :account
before_filter { |c| c.account = Account.find_by_subdomain(c.request.subdomains.first) }

… which makes the account (such as __myaccount__) available as the object _account_ to your methods.

Where else do account-based subdomains make sense? __Development & Testing__! If you’re writing an application that provides multiple user roles (administrator, new user, guest, etc), you’ll want an easy way to login as different users. What could be easier than having several users’ login screens bookmarked (yes, now your account is bookmarkable too!) with their passwords saved in your browser? That’s a lot less logging in and logging out, you can have several accounts active in different tabs or windows in the browser, and well, we won’t talk too much about the sheer coolness factor of having my username in a url, right?

I intend to use account-based subdomains in my future development efforts. What about you?

[1]: http://basecamphq.com/
[2]: http://www.adel.nursat.kz/apg/
[3]: http://wiki.rubyonrails.com/rails/pages/HowToUseSubdomainsAsAccountKeys

Post a Comment

Your email is never published nor shared. Required fields are marked *
*
*