When you auto-create subdomains on user signup does it create a new website or gives appearance of a website?

Question

Hi,

I am wondering if subdomains that are created upon signup become websites or do they just give the illusion that they are websites sort of like example.com/username?

I am trying to create something like user.domain.com and can't really find something helpful to do it? Is there a way I do it so that i can allow customizations for the account for clients?

I need them to be like standalone websites so that i can go and customize them upon client requests, so what is the best way to go about it?

Answer 1

Subdomains usually map to a specific path on the webserver. For example, Apache specifies these paths in httpd.conf, they are called VirtualHost. An example may look like this:

<VirtualHost *:80>
ServerName subdomain.domain.org
DocumentRoot "apache2/htdocs/domain/"
</VirtualHost>

This entry maps the Uri subdomain.domain.org to the path apache2/htdocs/domain/. Now, you can modify or present a page in that path, and it won't collide with other sites.

Answer 2

The answer is quite specific to where you're signing up. There's no intrinsic connection between domains, subdomains, and hosting accounts -- you could have example.com hosted somewhere, and subdomain.example.com hosted somewhere totally different if you wanted. It's all about your host, their setup, and how you/they set up DNS.

You could accomplish this somewhat easily by having two sites, one for example.com and one for *.example.com, and have the latter base the document root on the first part of the name. In Apache, this is as simple as

VirtualDocumentRoot /path/to/site/subdomains/%1

As far as a browser would be concerned, each name represents a different site, and there'd be little or no leakage between sites if cookies are set up properly. The only problem would be FTP access, if you decide to grant that -- each user would have to be set up to have their subdir as their home dir, and ideally chrooted or something so they couldn't go and look at other people's stuff. Obviously, that will require some cooperation with/from your web host. (At the very least, in order to use VirtualDocumentRoot, they'd need to have mod_vhost_alias running. There are other ways involving mod_rewrite, but any way you do it is going to have the same issue with FTP access.)

Answer 3

Your DNS record will need a wildcard for *.domain.com this will allow others to know that jack.domain.com leads to a valid location.

Once that is done, your .htaccess will need to know how to handle a *.domain.com requests. More information on this can be found at htaccess subdomain redirect rules.

The gist of it is that someone goes to jack.domain.com your server sees this and then says, Ok we are passing jack as part of the query string so each page can see we are working under jack. Then in your scripts you would just use that information to pull it up and display the data for jack.

There are many different ways this can be setup, so it is hard to say how to tailor to your needs. But hopefully that is enough information to get you started. Just remember, if you are testing on localhost, localhost HOST file does not allow wildcard DNS names, so for testing you have to manually add each subdomain to that host file for testing.

Answer 4

Others have answered the main points of your question, but I did want to touch on what you call the "illusion" of a website.

There are a few different ways to serve a given application in a domain, subdomain or directory, from static files, to a single file handling every request no matter what path or domain was requested. No method is more or less "real" than any other. The only method I would call an "illusion" would be a website masked behind another website using frames, which is generally a Really Bad Idea. (Try bookmarking on a site where the URL doesn't change as you click around.)