In my last post, How To Configure Umbraco To Work In A Load Balanced Environment I discussed in detail about the issues configuring Umbraco in a load balanced environment. One part of this configuration is that the Umbraco backend must only be available from a single node. If the backend is available from all nodes in the load balanced cluster then bad things can and probably will happen. As you should know, accessing the Umbraco backend for your website will be accessible at:
Having this URL available and public-facing not only causes issues for load balancing but it also creates security issues. When the admin URL is available for anyone to browse to, it can give hackers massive clues about CMS powering your website... Umbraco! Some hacker will have a script that will go through the internet and check the default admin paths for all the major CMS in order to try and compromise your website and the more information a hacker has the easier his job becomes. There are several ways you could potentially solve these issues. From my experience, the easiest and quickest to set-up is creating a dedicated sub-domain for all your Umbraco admin/content editing access and block access to the Umbraco backend from your primary websites URL. Lucky, setting up Umbraco to work this way is pretty pain-free and in today's guide, I'm going to cover everything you'll need to do this.
What Will I Need To Configure Umbraco in A Load Balanced Environment?
Ok, so in order to get started you will need the following:
- URL REWRITE Url Rewrite installed on all your nodes. If you've never used Url Rewrite it's a Microsoft extension that plugs into IIS. You can download it here.
- An Admin Sub-domain In order to get the admin working on a single node the easiest way to do this is to create an admin sub-domain. It can be public facing, or simply internal if you don't want anyone outside of your network having access to it. You need this domain set-up as a binding on ONE of the nodes in the cluster only.
- Decide on a WWW or non-WWW URL strategy You need to consider how you will handle the WWW or non-WWW Url debate. More information about this can be found in this article, Setting Up Umbraco To Always Use WWW Links. If you use a WWW approach you will change your WWW rule to ignore the sub-domain
How To Set-up Your Umbraco Web.config For A Load-Balanced Environment?
If you followed the steps above, I'm assuming your website uses a WWW URL strategy and you have a rule similar to the one below in your section in your web.config:
This rule tells IIS to redirect any traffic to your website that doesn't have WWW. In today's post, I'm going to use the sub-domain admin.website.com to allow content editors access to the Umbraco backend. If you had a similar rule in your config then accessing that sub-domain will never work as it will always be re-directed to www.admin.website.com, which we don't want. Instead, we need to slightly change that rule to ignore the sub-domain, 'admin'. To achieve this in my example above, in the conditions element, the HTTP_HOST condition needs to be updated to allow www and admin . You can do this by making the following change:
If you have your subdomain set-up, public-facing, and the sub-domain configure against your website entry in IIS (ALSO, it should only be on one of the nodes in the cluster if you're load balancing) when you try and view your Umbraco backend with the subdomain it should work. Just in case there is any confusion, in my example, this Url should load the backend of your website without a 404, or, 500.
If this doesn't work you need to do some troubleshooting, as it should work fine if everything is set-up correctly. Do not carry on until this step works as all you will do is lock out anyone from using the backend. If you do encounter issues, some common issues might include:
- The sub-domain isn't public facing properly
- The domain needs more time to propagate
- The binding in IIS has a typo
- You have some other URL Redirect rules causing issue
Disabling Access To The Backend From The Main Domain
The next step in the process is to disable all access to the backend via your main domain. Doing this will mean the backend can only be accessed via your sub-domain. In your web.config section, you need to add this rule (after the WWW rule if you have one)
What this rule does is match any Url's that contain /umbraco/ in the URL against your primary website domain. The primary website domain is set in the HTTP_HOST condition. When implementing this you will need to change www.website.com to your primary domain. After implementing this you should now have blocked anyone accessing your Umbraco backend via the primary domain, increasing security. If you have a load-balanced environment you are now forcing all content editing requests to go via one node which is how your site must be configured if you don't want it to break in weird and unwonderful ways.
One issue that might cause you some problems with this approach is that the backend preview will use the sub-domain. In most websites this won't matter, but if you have any code that is environment-specific, you need to make sure it will work with the sub-domain as well.