Subdomain Redirection

Community Server is a community oriented web application that provides forums, blog, and other functionality. While this is nice it is often desirable to use its components in such a way that a component is separated from the main community. For instance, if you only want forums on your site, you want to use the software solely for its blogging functionality, or any other desired purpose. The SubdomainModule class of TimothyHumphrey.CommunityServer provides a means to accomplish this.

The SubdomainModule class internally redirects specific urls to specific portions of Community Server; it can also intercept links before they are rendered and change them to appear to be within the subdomain url used to access the page. The net effect is that a portion of Community Server can be isolated from the entire community and appear to be a standalone application while unaffecting the rest of the community.

For example, normally blogs are stored under the blogs/(blog) directory, where (blog) is the blog name. To access a blog named "personal" you would normally use http://server.com/blogs/personal. With the SubdomainModule class you could have a subdomain called "personal" that points to this url and access it with the following url, http://personal.server.com.

Usage

Three files are touched to use the SubdomainModule class.

1. Edit your application's web.config file and add the following entry to the top of your <httpModules> section.

   <add name="SubdomainModule" type="TimothyHumphrey.CommunityServer.SubdomainModule, TimothyHumphrey.CommunityServer" />

   It is important that this line be at the top, or at the very least above the CommunityServer entry, so that it can take affect before Community Server. Your <httpModules> section should look similar to the following when done.

   <httpModules>
  <add name="SubdomainModule" type="TimothyHumphrey.CommunityServer.SubdomainModule, TimothyHumphrey.CommunityServer" />
  <add name="CommunityServer" type="CommunityServer.CSHttpModule, CommunityServer.Components" />
  ...
</httpModules>

2. SiteUrls.config is where you specify the subdomain redirections. The following sample illustrates subdomain redirection.

   <subdomains>
  <subdomain domain="blog.timothyhumphrey.name" path="$weblogs/blog" />
  <subdomain domain="localhost/csweb" path="${reader}" />
</subdomains>

   Each <subdomain> entry defines a different subdomain redirection; there is no limit to how many there can be. Each entry is compared against the incoming url and if a match is found processing is done. Specifically, the domain attribute of each entry is compared against the incoming url. For example, given the following url, blog.timothyhumphrey.name/archive/category/1003.aspx, the first <subdomain> entry would match it. When a match is found the path attribute of the <subdomain> entry specifies where in the Community Server url hierarchy the request should go. In this case it would go to the location where blogs are kept and then the blog named "blog".

   Notice that the location of the weblogs from the preceding example is specified as a variable, $weblogs. The SubdomainModule uses variables to refer to locations defined within the <locations> node of the SiteUrls.config file. For this reason it is recommended that you place the <subdomains> node near it for easy reference when defining your subdomains.

   Variables begin with a dollar sign $ and are followed be a name which should match a name defined within the <locations> node. The name part of a variable may be surrounded by braces { } as in the second <subdomain> entry in the sample listed earlier.

   Also, notice that in the second example entry the server name, localhost, is followed by a path. This indicates that the subdomain to be matched need not technically be a subdomain, any part of the url up to any query string is checked. However, any subdomain specified should at least include the base url of the location the application is stored. For instance, using the second <subdomain> entry of the sample, the domain attribute must be at least localhost/csweb, and not simply localhost, if the Community Server application is stored under the csweb directory. This normally need not be remembered, but it bears mentioning.

   <location> entries in SiteUrls.config with the exclude attribute set to true will not be redirected should a url matching them be encountered. For instance, the control panel in Community Server is used to make administrative changes and is accessed with the following url from the root Community Server site, /controlpanel. Given the first sample listed earlier this url would be redirected to a blog, preventing access to the control panel if the following were the full url, blog.timothyhumphrey.name/controlpanel.

   As part of the SubdomainModule's processing it removes the subdomain portion of the url, in this case blog.timothyhumphrey.name, and compares the url that remains against <location> entries with their exclude attributes set to true. If a match is found no redirection is performed. So the url blog.timothyhumphrey.name/controlpanel will not be redirected to a blog and so the control panel may be used as normal. In addition to the exclude attribute the SubdomainModule also checks a custom attribute it supports named subdomainExclude. This attribute works exactly as the exclude attribute does but since it is not known to Community Server it provides a means to indicate to the SubdomainModule to exclude a url while still allowing Community Server to include it. Adding additional <location> entries is how you may indicate to the SubdomainModule that certain urls should not be redirected. In fact you may want to add the following entries to enable logging in to Community Server even with redirection in place.

   <location name="login" path="/login.aspx" subdomainExclude="true" />
<location name="logout" path="/logout.aspx" subdomainExclude="true" />

3. The communityserver.config file is optionally modified, but recommended. An entry to this file is made so that the links Community Server renders are altered to appear to come from the subdomain. For instance, a link to a blog category might normally appear as /blogs/blog/archive/category/1003.aspx but will get altered to be /archive/category/1003.aspx.

   The entry that is made is a new SiteUrlsDataProvider. It is easiest to search for the occurrence of this phrase in this file to find the entry containing it. You will have to comment out the existing entry provided by Community Server and replace it with the one provided by TimothyHumphrey.CommunityServer, like so:

   <!--
<add
  name = "SiteUrlsDataProvider"
  type = "CommunityServer.Components.SiteUrlsData, CommunityServer.Components"
  path = "SiteUrls.config"
/>
-->
<add
  name = "SiteUrlsDataProvider"
  type = "TimothyHumphrey.CommunityServer.SiteUrlsData, TimothyHumphrey.CommunityServer"
  path = "SiteUrls.config"
/>

The entries in the <subdomains> node of the SiteUrls.config file are read when the Community Server application is started and never again. This helps to speed up the subdomain redirection processing but can make editing of the subdomain configuration more difficult. To overcome this a special url can be used to force the SubdomainModule to re-read the subdomains. Going to /subdomains.axd will cause the SubdomainModule to re-read the subdomains. The slash / character at the front indicates it is referenced from the root of the Community Server url. For instance, if Community Server were installed at localhost/csweb then the following would be the address of the subdomains.axd file, localhost/csweb/subdomains.axd. Similarly, if this were the install location, blog.timothyhumphrey.name, this would be the subdomains.axd url, blog.timothyhumphrey.name/subdomains.axd.