If there was a way for me to send an email to myself in the past, I would send the following messages:
- Last Week’s Lottery Numbers
- A Reminder Not to See Spiderman 3
- Reasons to Not Use Subdomains in a Web Application
In Wufoo, we use subdomains to differentiate user accounts (http://username.wufoo.com/forms/) and honestly, it’s been nothing but trouble for us from a development standpoint. If we could do it all over again, we would have definitely handled our urls and account settings using a Flickr style setup using folders (http://wufoo.com/forms/username/). Here’s some reasons why:
Reason the First : When you want to offer your users SSL on these accounts, you have to buy a wildcard subdomain certificate that’ll cost way more than your normal SSL certificate. Prices range between $899 to $200 a year. We use Godaddy. Their interface leaves something to be desired, but they’re one of the cheapest and we love their customer support. One thing that we don’t like is that, since that certificate only works with subdomains, we have to do things like
https://secure.wufoo.com/login/to get an encrypted login url rather than having a simple url like thishttps://wufoo.com/login/for our users to follow (and we’ll be damned before having to pay for two different certificates just for this kind of functionality). If we had just set up users to have their own directory as opposed to a subdomain, we’d have only needed to purchase a regular SSL certificate, which you can get for as little as $20 a year, and avoided Reason the Second.Reason the Second : Setting up subdomains in a development environment (like on your localhost or svn) is a complete and total pain in the ass. Version control is a must in any serious web development environment and so it’s important that you can recreate all the things you have on your live server on your development setups. Unfortunately, with subdomains you can’t do this easily on a localhost and it’ll usually result in you having to 1) buy another domain to test these subdomain accounts and 2) branch out your code to behave differently (set a specific account as the default) when its working on a localhost. It’s not ideal and results in extra time being wasted when you’re trying to debug and test.
In the end, working with subdomains as a way to set up user accounts in a web application is definitely doable, but an experience we wouldn’t like to repeat again. We’ll try to share some tips on what we’ve done to lessen our pain down the road, but we’re still ironing them out to this day. If you can avoid them, please do because you’ll save yourself some money and some headaches.
We’re using DHH’s account_location plugin and we just add something like the following in /etc/hosts on the development machines:
127.0.0.1 localhost.x username1.localhost.x username2.localhost.x
No major issues, it all just works.
Thijs: Except maybe that your browser-based application may need to write to your /etc/hosts file… far from ideal either ;)
I totally agree with you on this. Originally for http://www.indiefy.com I was going to use subdomains for the artist profile’s, but decided to go with a myspace style folder approach I.E. http://www.indiefy.com/motiveformovement
Using MAMP Pro on OS X, I recently set up project.client.staging.c77studios.com and, locally, project.client.dev.localhost. Worked great. Not sure that helps with your situation, though.
Thijs beat me to this (I think), but I was going to suggest mod_rewrite or the like. On your server its a folder structure, but to the user its being served as subdomains.
Thanks for this tip because now I’ll stay away from subdomains on my next great web app! :)
Problem #2 could be solved once and for all by a publicly resolvable domain with wildcard subdomains resolving to 127.0.0.1 - I swear I knew of one but can’t find it now.
you should befriend one of the folks at facebook and find out how they support a subdomain for every college, university, highschool and metro area in the US. Seems like it’d be a similar problem.
Sean, not really a similar problem. They don’t have SSL for most of those subdomains, for one.
You mention managing dev environments on local machines, how do you manage database and table changes across different developer local environments?Say, Developer A makes a table change and a code change. He commits his code via Subversion and updates the dev/staging server table. Developer B does an SVN Update to get the code changes, but how will he know exactly what table changes he needs to make to be up to date?
I assume you meant “$899 to $2000”?
Pricey. Thanks for the tip, though.
All database changes have to be made with scripts. So you commit a script to the dev server, and when developer B does an update, he runs that script locally.
By the way, you can get a RapidSSL wildcard cert for only $199 per year.
I’d be curious why you wanted subdomains in the first place. Sure, they suck for developing, but there must have been some darn good motivations for trying, right?
I kinda always had that feeling, but thanks for the confirmation.
Just set up a local DNS server through which you setup all your development domains. Then, check in the configuration file for the DNS server into SVN so that that is nicely tied in with any application dependencies
It might be worth reading some of the discussion at http://community.livejournal.com/lj_dev/ — the LiveJournal people ended up going with lots of subdomains in order to fix XSS security problems with user-generated content.
I agree with you - it sucks to have to pay for that certificate. But I’m pretty sure that GoDaddy’s virtual dedicated servers allow you to auto-tweak the httpd.conf file (or something similar) and thus auto generate virtual domains/ sub-domains. It’s been 10 years since I last did this on a Linux server I had control of, so I unfortunately don’t remember the details.
On the other hand, you build much higher PR by using subdirectories rather than subdomains, anyway. So ignore what I said :)
@Kevin, that may be the case in your circumstance but (like your system) I had to develop a shopping system that had multiple stores under the same domain. I went the sub domain route and don’t regret it one bit. In fact, I think that it was the best option.
First, you don’t have to worry about separating sessions as they can’t cross over sub-domains. So if a user goes from one virtual site to another, you’re covered with no extra work.
With your ‘secure.wufoo.com’ issue. I would have simply resolved myself to be a little non-web 2.0ish and forced ‘www.wufoo.com’ (does this make me an old fart?). This way, all users use the ‘www’ subdomain and so does your ssl.
I think the cleanliness of sub domains makes it just a little more personalised for the end user - making the extra SSL expense worth it.
I also use a second domain with a wildcard subdomains pointed to 127.0.0.1 I’ve never had any trouble developing with subdomains locally. I also modify the host file to create subdomains for the one’s I test most often. That way I can develop locally without problems.
Stefan: We’re talking about the development environment i.e. ‘Reason the Second’.
Thanks.. great tip!
Reason the Third: Phishing. See http://auth.wufoo.com/forms/welcome/
I just created it to demonstrate what happens when you allow untrusted users to register subdomains. Not using this for anything.
In case it’s not clear, it’s not the look of the form alone that makes it dangerous, it’s the fact that it has a domain called auth.wufoo.com
You have a good point, Philip. We have had to put quite a few checks into place to combat phishing, and it is always a pain. We’re leaving your form up just so people understand the point. I placed a small disclaimer at the bottom to be safe.
Thanks so much for sharing this, Kevin! I’ve been considering using subdomain user addresses for a project I’m working on, so this comes at a great time.
“Unfortunately, with subdomains you can’t do this easily on a localhost and it’ll usually result in you having to 1) buy another domain to test these subdomain accounts and 2) branch out your code to behave differently”
This is totally untrue. Ever heard of a customized HOSTS file ? Found in the c:WINDOWS** or c:WINNT** (exact location depends on your version of windows, it’s often c:/WINDOWS/system32/drivers/etc/hosts) or /etc/hosts under unix, you can very easely reroute your own domain and subdomain at will to localhost, provided you configured your virtual hosting correctly under apache/tomcat/whatever you use.
This is good. I was thinking of doing some research on the subdomain for users for my website http://www.funkychica.com. I am glad I read this. Thanks!
Everyone needs a hug.
I agree that this adds many extra degrees of difficulty for development but you end up sacrificing a strength of the app. Having personalized sub-domains may be worth the cause of the pain. I can understand not using them for social network / community type sites, though. In some cases I think I might think twice before signing up for a web service that I knew I would be using quite often and would not have the ability to go to or send a client directly to myDomain.theAppDomain.com. To me, the customer, I believe I would think twice if I knew I might get the subdomain with the competitor’s service. I guess it depends on what’s being offered.
Alternatively, I think it could be smart to give people the subdomain, but just for redirection purposes. So, they could use this: myDomain.theAppDomain.com but it would route (redirect) them to: http://theAppDomain.com/myDomain/ to sign in.
I know you guys are a PHP shop, but in Rails we’ve done stuff like this in the past:
# config/routes.rb if RAILS_ENV == 'development' map.connect '/mobile', :controller => { :mobile } else map.connect '', :controller => { :mobile }, :subdomain => { 'm' } endSo, in production http://m.chow.com works, but for development you go to http://localhost:3000/mobile so you don’t need to bother with /etc/hosts.
By using subdomain, it save u some money from purchase new domain.
As for the phishing example in #24: Now is http://wufoo.com/forms/auth/welcome/ (the folder variation) any better than http://auth.wufoo.com/forms/welcome/ (the sub-domain variation)?
I can see your point when it comes to ssl. One domain is easier and cheaper. I can see the point about phishing, but this will always be so if you allow a user to insert a form into a page. Any page.
I wouldn’t, however, say developing with subdomains is a problem. I have used/tested them on both mac and windows test servers without problem. My only pain was adding the subdomains to the host/NetInfo Manager one at a time. Not a problem for testing as you will never have to do more than 20 or so. Subdomains are easy for end users to remember, make them feel special and make the general url structure shorter and easier to pass between friends.
Agreed about the phishing problem. http://wufoo.com/forms/auth/welcome/ is no better than http://auth.wufoo.com/forms/welcome/
You don’t need to use the NetInfo Manager. You can instruct it to use /etc/hosts. Just put this into /etc/lookupd/hosts:
LookupOrder Cache FF NI DNS DS
(FF mean flat file = /etc/hosts)
You might have to kill -HUP the lookupd.
yea i see your points and we made the same choice a good while ago at http://1timetracking.com. We have pretty big databases for each user and each domain is for a company so i think it makes more sense. I think the subdomain idea gives the end user more ownership of what they have purchased or subscribed to.
I do think in your situation it probable wasn’t needed. I think like with basecamp if the users have other external users coming to the app then there is value in it.
Those are two very good points. Why make more work for yourself and require more money for SSL certificates when using a folder name will work just as well? Save yourself a headache and heed this sage advice.
I think everyone has come to a great conclusion, but what is the best method for creating ‘folders’ ala http://www.mysite.com/username. I assume this would be done by adding a rule to the apache rewrite engine? Or is it an actual folder? Thoughts?