Word Front is proud to present our latest product offerings: t-shirts, apparel, and accessories via our Word Front Wares Store.

Each garment is hand-crafted out of only the finest organic and synthetic materials, and features an exciting and edgy graphic design that is sure to turn heads (and hearts).

All of our garments are professionally plot printed on high-quality heavyweight material that will withstand years of wearing and washing. SpreadShirt is handling production and shipping. We’re very excited about this new venture, and hope you’ll check out our store.

We’ll be adding new designs every Wednesday (more often throughout February) and will use this space to talk about new products and designs.

Expect updates, re-designs, and new content to be added to each of our sites soon.

http://example.com/members/profile.php?username=Bob

They’re able to simply log in to:

http://bob.example.com

It’s easier for them to remember, and it looks nice and clean. We’re all about clean livin’ here at Word Front.

Numerous sites create this subdomain for you when you sign up for an account, like Blogger does (pretty much all of our upcoming web applications will use this trick). This tutorial will show you how to create wildcard subdomains and allow users to log in to your member account system (assuming you have one) using their own user name as a subdomain (like http://username.example.com).

• Here’s a link down the page for our “Expert Mode Summary - Just the Nitty and Gritty” if you’re already adept at configuring your web server.

Before We Begin

First, for this tutorial we’re going to assume that you are using an Apache web server, Bind for DNS, and that you’re able to modify your web server and nameserver config files, which usually means that you’re running your own server and have root access.

If you’re using a shared hosting provider (you pay someone for some web space, and they set up everything on the server) then you should contact your web host or ISP to see if they offer “wildcard DNS” or “wildcard subdomains” for your account. Yes, you’ll also need to have your own domain name (a la example.com), and a static IP address (again, ask your provider) to create subdomains for your users. While you’re asking your provider about wildcard subdomains, you can also make sure that the Apache module “mod_rewrite” is installed, as we’ll be using it to re-direct the right user to the right place.

In addition to all of the server setup stuff, you’ll need to know a little PHP, ASP, JSP, PERL, or some other server-side scripting language to create the user login, which we won’t cover here. If it sounds complicated, that’s because it is. We’ll explain more below.

First Step: Wildcard DNS

You’ll need to add a “wildcard” entry to the DNS zone for your server. If your eyes just glazed over, don’t fret. Most web server administration packages, like Cpanel and Plesk, offer a means of editing a DNS zone through a pretty browser interface.

If not, though, you’ll need to open named.conf and add this line to the end of the DNS zone for the domain for which you want to enable wildcard domains:

*.example.com. 14400 IN A 123.456.789.012

Let’s break this down a little. The asterisk (*) is the wildcard, and it’s telling the DNS system that ANY subdomain should point to your main account IP (I used 123.456.789.012 as an example, but you should put your own IP address here).

Note the period after the example.com. That’s important.

Now save the config file and restart Bind (either from your web-based control panel or from your SSH access while logged in as root - on most Linux servers it’s “service named restart” or “/etc/init.d/named restart”).

Edit Apache’s VirtualHost Directives

Okay, now we’re going to edit a line in Apache’s configuration file, httpd.conf.

Open httpd.conf in your favourite text editor (from the shell, change the directory to where httpd.conf is located, and then type “pico httpd.conf”) and scroll down, usually way way down, to where the VirtualHost directive is set up for your domain. It should look something like this:

<virtualhost 123.456.789.012>
ServerAlias www.example.com example.com
ServerAdmin webmaster@example.com
DocumentRoot /home/example/public_html
BytesLog domlogs/example.com-bytes_log
ServerName www.example.com
<ifmodule mod_userdir.c>
Userdir disabled
Userdir enabled example
</ifmodule>
<ifmodule mod_php4.c>
php_admin_value open_basedir "/home/example:/usr/lib/php:/usr/local/lib/php:/tmp"
</ifmodule>
User example
Group example
CustomLog domlogs/example.com combined
ScriptAlias /cgi-bin/ /home/example/public_html/cgi-bin/
</virtualhost>

If you don’t have exactly those parameters, it’s probably because your server is set up differently than ours. The important part is:

ServerAlias www.example.com example.com

We’re going to now add a new alias to match the new wildcard subdomain we added in Bind:

ServerAlias www.example.com example.com *.example.com

This time there’s no period after the .com

Save httpd.conf and restart Apache (”service httpd restart”).

If all you wanted to do was to point any subdomain to your main index page, you’re done. At this point anything.example.com will direct you to example.com.

Getting Tricky: mod_rewrite

Here’s where your hard work pays off. Using the magic/voodoo of mod_rewrite, you can let users log in to your membership system using their own special subdomain on your server.

You can add the rewrite code right into httpd.conf but in case you need your web host to set up wildcard DNS for you, we’ll keep things flexible by adding the needed code in a file you can keep in your own web space (this way you can edit it anytime you want and you won’t interfere with other accounts on your server - and also you can edit this file without having to restart Apache, which is a bonus, especially if you’re experimenting and changing things a lot).

First, check to see if there’s a file called .htaccess in the root directory of your web site (usually public_html/).

If not, open your text editor (we like Textpad but Notepad will do - you just can’t use a word processor like Word) and create a new plain text file called “.htaccess” (yes, with a leading dot - it’s an extension with no file name - in Windows you can put quotes around it when you save the text file so that Windows allows the filename-less file).

Add the following to your .htaccess file:

RewriteEngine On
RewriteRule ^\.htaccess$ - [F]
RewriteCond %{HTTP_HOST} !^www\.example\.com?$
RewriteCond %{HTTP_HOST} ^([^.]+)\.example\.com?$
RewriteRule ^$ /members/index.php [L]

The first line turns on the URL rewriting engine.

The second line doesn’t let people access your .htaccess file. You don’t really want people reading from (or writing to!) this file.

The next two lines set up the conditions that will have to be met in order for the URL to be rewritten.

The third line allows the “www.example.com” subdomain to still work, while the third line matches every other subdomain.

The fourth line is where the redirection happens - any URL meeting the previous two conditions are redirected (quietly, without changing the URL text) to a PHP script.

You could alternately write the fourth line like:

RewriteRule ^(.*)$ /members/index.php?userName=%1 [L]

Then the userName GET variable will be sent to the index.php script (or whatever server-side script you’re using).

Keep in mind that we’re not actually redirecting to another page from the user’s point of view - they’ll still see their username.example.com in their web browser.

Now any subdomain other than “www.example.com” will be redirected in the background to “/members/index.php“.

Scraping the User Name

In your script, you’ll be able to parse the user name based either on the URL string or the GET variable you’ve sent, and can present the user with a login form so they can log in. You can even set the value of the user name input since you’re getting it from the URL.

NOTE: You’re not actually authenticating a user based on just the URL string - you’re simply using your script to log them in as you ordinarily would, but instead of seeing a generic URL they’re seeing their own private URL.

After logging them in you can set a cookie so that when they return to http://username.example.com they’re already logged in and presented with their start page (whatever that may be).

Here’s some sample PHP code to grab their user name from the subdomain string:

<?php

// Get HTTP request info
$serverHost = explode( '.' , $_SERVER['HTTP_HOST']);

// Get subdomain
$subdomain = $serverHost[0];

// Display it for test purposes
echo "The subdomain is: " . $subdomain;
?>

Give it a try. You should be able to type in pretty much anything and see “The subdomain is: ______” on that page.

That’s it. You’re now able to have your users log in to your site with their own subdomain!

Expert Summary: Nitty & Gritty

If you’re already proficient with setting up Apache, Bind, and know PHP inside and out, here’s a briefer explanation of what you need to do.

For all steps replace “example.com” with your domain name, and “123.456.789.012″ with your static IP address (you’ll need one to set up wildcard DNS).

1. Add *.emample.com. 14400 IN A 123.456.789.012 to the DNS zone for your domain, then restart the nameserver.
2. Add the wildcard server alias to your web server’s config file, like ServerAlias www.example.com example.com *.example.com - and then restart the web server.
3. Add the following to .htaccess:
   

   RewriteEngine On
RewriteRule ^\.htaccess$ - [F]
RewriteCond %{HTTP_HOST} !^www\.example\.com?$
RewriteCond %{HTTP_HOST} ^([^.]+)\.example\.com?$
RewriteRule ^$ /members/index.php [L]

4. Capture the user name with PHP or some other server-side scripting language, just for the sake of presentation, and NOT for actually authenticating the user.
5. Log them in as you ordinarily would. The only difference now is that they see their custom subdomain page in the address bar rather than some awkward generic login page. Also, to access their account they can type an easier to remember URL rather than having to navigate your site, and if you set a cookie on login they’ll be able to get right to their data by setting a bookmark or returning to their private URL.

Custom wildcard subdomains are especially useful if your web service offers a way for people to publically share their data with others. For instance, if you had a site where people could share photos, their public photo sharing page could be username.example.com and people could direct their friends to that page to see their photos.

The possibilities are vast.

That’s it for this tutorial on setting up wildcard subdomains on your web server. If you have any questions or suggestions, please leave a comment below.

Our aim is to keep our articles and examples as easy and simple to understand as possible, offering up tips we’ve collected over the past decade, with the intention of helping other designers make everything that falls under the big blanket of “web design” easier.

We hope to engender an environment of helpful sharing here, and to that end we encourage comments and discussion, even if it’s to disagree with us or point out the flaws in our work.

Expect this site to be updated a few times per week. You can subscribe to our RSS syndication feeds if you want to be notified of updates. Links are at the end of each archived article as well as in the footer of every page.