Portal Alias, What is it?

In a nutshell, the PortalAlias is used to determine exactly which portal in your DotNetNuke installation is being requested.

A little History
This feature it a pretty important piece of the DNN pie since hosting multiple portals under one IIS website and one set of website files and one Database is one of the best features of DNN (imho). As a matter of fact, this feature was probably the most attractive added enhancement to the IBuySpy workshop, and in DNN 1.x & 2.x the way it worked didn't change much if at all. Then in 3.x we added the ability to have Wildcard portal aliases.  This latest feature was often requested because people wanted the ability for a specific portal to "catch" all the traffic that was directed for a particular domain name.  This would in turn allow them to be able to have portal1.domain.com, portal2.domain.com, portal3.domain.com, etc.,  all running off the same portal.  Putting a manual entry into the Alias table for each of these would have worked, but it would be even nicer if someone could just put domain.com, or *.domain.com.  So we made it so.

No more DotNetNuke Configuration Error
We also realized that as long as we were adding a wildcard feature, that we should probably get rid of the dreaded message that you had somehow royally messed up your portal, just because someone happened to navigate to your site with  a Url that you didn't have setup as a portal alias.  Those of you that have been around for a while no what I mean. For those that don't you can still see that this error is still a rather common one by searching google for "DotNetNuke Configuration Error"   Don't  be alarmed, most of those portals are probably working portals, but the efficient spiders of google have found ways to get to these 2.x portals by ways that were not setup.

It get's complicated
As with all maturing software that is trying to handle more and more use cases and feature requests, the code gets a lot more complicated.  Not only was this feature added in 3.0, but we also added search engine Friendly Urls.  Making all these work together drove the number of possible scenarios up pretty high, and as I was working on a bug that was keeping the portal alias wildcard feature from working correctly, I got pretty intimate with the code.  The only way I could get the wildcard feature to work reliably across DNN instances with multiple portals that each wanted to implement wildcards and hide the dotnetnuke configuration error if no alias could be matched at all was to redirect to the first alias of the default portal if all methods to figure out what actual portal was being requested were exhasted.  This actually adds another benefit though, and one that should really be available in any website, but that we hadn't really had in DNN. The benefit of looking up the first alias of the first portal is that you can put a url to whatever page you wish in there.  So if you were to put a Url in the first alias of something like domain.com/Custom404.htm then you could have a nicely formatted custom page/portal not found error. 

Why does my site redirect to localhost?
This is also what causes one of the most frequently asked questions on the forums, "Why does my site redirect to localhost?".  This is because most people will install DNN on localhost, then copy their DB and web files up to their server and try to access the site through a different Url.  I have a new fix for this though, which should really cut down on this common problem, and I hope to get it into 3.2.  The new fix is to check first to see if there is more than one portal, if not just let the default portal get all traffic that comes it's way. I know what you're saying. "Sheesh, why didn't that get included a long time ago".  Well, like I said it's complicated.

The details for those so inclined
Here are the steps that DNN uses to go about trying to find out which portal is being requested from the Url.  This takes place in the UrlRewrite HTTP Module (UrlRewiteModule.vb) in the OnBeginRequest sub which is a handler for the application.BeginRequest method and is basically the entry point for each and every request that gets handled by DNN.  These steps are for DNN 3.x portals.

1. Get the Url that was used to access the site.
2. Do some checks to make sure that the request is not a hacking attempt .
3. check to see if it's actuall install.aspx that is being called, if so then exit since this is a global page.
4. Apply the rules from SiteUrls.config (in the root of the DNN website). These  rules are used to Rewrite the Url into a friendly one.
5. Get the TabId and/or the PortalId from the Url as either of these can be used to uniquely identify a particular portal. The TabId is also needed to go to the specific page being requested.
6.  Look for an "alias" querystring value on the Url which can be used directly to look up the portal from the PortalAlias table.
7. Get the DomainName portion of the Url, to be used if one of the other more specific methods (tabid, portalid, alias) can't locate the portal. This is the wildcard feature.
8. If none of these produce a portal, then lookup the Host's default portal and use the first alias for a redirect.
9. That is basically it, isn't that enough?

So there you have it. PortalAlias explained.  Feel free to ask questions in the comments.  I know I'll be sending people here now to learn more about how a little of the magic happens in DNN, so if there is anything to add lets make it happen.