Changing Umbraco's backoffice address

By default your backoffice would be accessible at /umbraco. This not only provides users an opportunity to (try and) access the backoffice but it also divulges the fact that you are using Umbraco and .Net and it may be possible to exploit this - neither Umbraco nor .Net are flawless.

So it should be best practice to remove change this, right? Luckily there are a couple ways of doing this.

• Changing the name of the physical /umbraco folder;
• Only allow access to the backoffice via a subdomain of the site.

My preferred way is the second option, to only allow access to the backoffice via a subdomain of the site. This is purely because it work regardless of the version of Umbraco being used and keeps the /umbraco path in place, disrupting the install as little as possible.

 

Changing the physical path

I have attempted this in the past with various v4 and v6 installs and it has not worked or at least caused bugs. See this thread for a discussion of the technique. My impression is that even in v7 this is still not possible without tweaking the source. However, I would love to be corrected if this is now possible in v7.

 

Only allow access to the backoffice via a subdomain of the site

We can use URL rewriting to "move" the backoffice to an entirely separate subdomain, e.g. http://bo-admin.example.com/umbraco. For this you will need URL Rewite 2 installed in IIS, or something else that you are comfortable with that does the same. 

First, add a subdomain binding to your site in IIS. This subdomain will purely be for access to the backoffice and can be named anything, e.g. bo-admin.example.com.

Once added, you should now be able to access the site and therefore backoffice login page via this subdomain. On my site however, I have a redirect rule set up to catch from any URL that doesn't begin with www and redirect it back. This just needs amending to cater for the new subdomain:

This now ensures that visiting bo-admin.example.com doesn't redirect to www.bo-admin.example.com.

 Finally, you need to prevent access to the default backoffice. I think it is best to do this with by serving a 404 instead:

This will now prevent anyone from accessing Umbraco on the main domain. 

 

Caveats

The biggest caveat with this second subdomain method is that previewing the pages will happen on this subdomain. This may not be an issue but some sites may have a reliance on the primary domain, e.g. cookie domain settings. 

I'm sure there are other ways to achieve this but this is the one that works best and is eaiest to implement for me. If there are other ways, please do let me know.

Tags: Umbraco
Published: 20 February 2015