Don't Forget To Reserve Subdomains For Yourself // RailsTips.org by John Nunemaker

Don't Forget To Reserve Subdomains For Yourself

June 24th, 2008

In a certain application I’m working on, each account gets a unique subdomain. Something that is important, that most people don’t mention when showing examples of how to do account subdomainage, is how to reserve some for yourself and what are some good ones to reserve.

Here is a simplified version of the model I’m using:

class Account < ActiveRecord::Base
  ReservedSubdomains = %w[admin blog dev ftp mail pop pop3 imap smtp stage stats status www]
  validates_exclusion_of :subdomain, :in => ReservedSubdomains, :message => 'is not allowed'
end

Then in rSpec, I use the following to make sure that none of the reserved subdomains can be used. One note: the have_error_on in the code below is a matcher that is a part of the rspec-on-rails-matchers plugin.

describe Account do
  it "should not allow use of reserved subdomains" do
    Account::ReservedSubdomains.each do |subdomain|
      Account.new(:subdomain => subdomain).should have_error_on(:subdomain)
    end
  end
end

So nothing too difficult is going on up there. In fact, it is just out of the box Rails. The key, and the reason I post this, is to remind you to protect some of the important subdomains like mail, pop and smtp and some of the less important ones like blog and status for yourself.

Posted by jnunemaker Filed in Core, Testing

14 Responses to “Don't Forget To Reserve Subdomains For Yourself”

Luke Redpath Says:
June 24th, 2008 at 02:59 PM
Good suggestion, although I’d like to recommend a change to your spec. At the moment, it doesn’t really offer much protection. If somebody accidentally removed “www” from ReservedDomains, the spec would still pass because it is directly coupled to the implementation.

Personally, I’d explicitly state the sub-domains in the test to stop this from happening (I think this is more important than the resulting duplication).
John Nunemaker Says:
June 24th, 2008 at 04:29 PM
@Luke – That’s a great point. I went back and forth a wee bit on the issue when I first put it in there and I’m thinking now I agree with you.
Josh Says:
June 25th, 2008 at 07:33 AM
I’m working on a project that also uses the subdomain-as-account-key pattern. I plan to use the blacklist approach outlined above as well as a minimum length:

validates_length_of :subdomain, :minimum=>5

It makes things a bit simpler to avoid having to manually list out all of the “standard” host names like www, ftp, pop, etc.
John Nunemaker Says:
June 25th, 2008 at 10:53 AM
@Josh – Yep, I didn’t show that but I have a minimum length as well. I think I set it at 6.
Luke Redpath Says:
June 27th, 2008 at 06:22 AM
Just setting a validation on the length is a nice little shortcut, although it’s arguably not as obvious to other developers why you’ve done it (at least, without looking at the specs, but it could be easily missed).
Ryan Heneise Says:
June 27th, 2008 at 02:01 PM
I use a wee plugin called NameNanny (http://locusfoc.us/2007/2/13/name-nanny-plugin), which provides both bad_words and reserved_words lists. To use, just add this to your model:

validates_wholesomeness_of :subdomain

I like the NameNanny approach because the reserved words are stored in a file that can be modified independently of the code. My reserved words list is currently at 85 words and counting, with 776 prohibited bad words!
Rick Sandhu Says:
June 29th, 2008 at 03:29 PM
John,

I want to pick your brain for a second, please have a look at my post over at Railsforum.com:

http://railsforum.com/viewtopic.php?id=19738

Since you’ve worked on an application using subdomain, I thought you would be good person to get some insight from…Thank you!
Richard Livsey Says:
July 13th, 2008 at 12:02 PM
I’ve just implemented something similar in an app I’m writing at the moment.

However, I generated the specs as follows:
```
describe Account do
  reserved = %w(list of subdomains)

  reserved.each do |subdomain|
    it "should reserve subdomain '#{subdomain}'" do    
      Account.new(:subdomain => subdomain).should have_error_on(:subdomain)
    end
  end
end
```
That way, you get told exactly which reserved subdomain isn’t protected.

Instead of: > Account should not allow use of reserved subdomains FAILED

You get: > Account should reserve subdomain ‘www’ FAILED

Makes it much easier to track things down.
Mihai Says:
July 25th, 2008 at 02:33 AM
@Ryan Heneise – this NameNanny is used by the the equivalent dot com domain ?

I have a friend who had a bad experience with the above, meaning some info got “retrieved” from him.
Rick Sandhu Says:
July 29th, 2008 at 12:44 AM
Can you please share your thoughts on caching subdomain based applications using memcache? It’s hard to apply currently available reference to subdomain based applications.
John Nunemaker Says:
July 29th, 2008 at 12:35 PM
@Rick – Not sure I understand what subdomains have to do with memcache. Can you explain further?
Rick Sandhu Says:
August 2nd, 2008 at 09:53 PM
Sorry for the confusion but let’s say I have the following setup:

http://pastie.org/246376

Community ~~-> has_many -~~> Events Community ~~-> has_many -~~> Categories Event ~~-> belongs_to -~~> Community Event ~~-> belongs_to -~~> Category Category ~~-> belongs_to -~~> Community Category ~~-> has_many -~~> Events

How would I go about caching the ‘index’, ‘category’ and the ‘show’ actions in my Events controller using Rails 2.1 caching in conjunction with Memcache?
John Nunemaker Says:
August 4th, 2008 at 12:00 AM
@Rick – Check out http://blog.leetsoft.com/2008/7/21/rockstar-memcaching
Rick Sandhu Says:
August 5th, 2008 at 05:45 PM
John,

Thank you very much for your prompt reply. I really appreciate you taking the time to respond. That link really helped me on how to apply various caching patterns to large scale sites. Thanks, again!

RailsTips.org