Mark Everard

Hello, I'm Mark – a PhD physicist turned technologist / architect.

Archive for March, 2013

Modifying Alloy Templates to work with EPiServer patches delivered via Nuget.

with one comment

Along with their latest CMS release, EPiServer have also changed the model that they use to deliver hot-fixes to partner developers. Previously they were delivered as a singular hot-fix obtained from Developer Support or were rolled into more major service-pack releases. From now on, hot-fixes and maintenance releases will be delivered directly from the EPiServer Nuget feed.

This is a seriously great improvement as it means  fixes get pushed directly to us on a more regular basis, rather than us having to identify issues and obtain fixes via Developer Support. As of now, EPiServer have already delivered 2 patch releases of EPiServer.CMS.Core onto their Nuget feed (versions 7.0.586.4 and 7.0.586.8 – kudos also for the better assembly versioning).

However to take maximum advantage of the new delivery model, you have to have your solutions set up to reference the EPiServer libraries from Nuget. The demo Alloy templates are not set up in this way. I’ve put the steps to make them update-able via Nuget below. You should do similar to your CMS7 solutions too.

1) Remove/Change the Configuration build tasks – (sorry Ted)

The Alloy templates have a method of chained configuration build tasks to create a series of both generic and site specific configuration build transforms. This results in the configuration files in your site root being overwritten entirely on every build. Unfortunately this doesn’t work well with Nuget which will apply any package configuration transforms to config files in the site root – meaning you have to manually reapply any Nuget changes into the [Configuration]/Common/Web.Common.config file. This doesn’t cut it for me, so I just removed the build tasks by deleting the Post-Build tasks in the .csproj. I’m sure there is a way to keep the chained transforms (if you like them) and have them built from the root config files but I’ll leave that for someone else 🙂

2) Delete [Libraries] folder from the installation

The Alloy solution is set up to reference the EPiServer libraries it needs directly from the [Libraries] folder within the solution. Instead we need to change this to so that the solution uses the EPiServer.CMS.Core and the EPiServer.Framework packages from EPiServer Nuget.

  • Delete the [Libraries] folder from the project
  • Remove all references to EPiServer from your project references. Also remove any references to StructureMap, log4net, NewtonSoft.Json and Castle.Core
  • Make sure you have the EPiServer Nuget feed added to your local Nuget tools.
  • Then you should run the following commands in the Nuget Package Manager Console – (which is absolutely the best way to work with Nuget)

Then you should run the following commands to install the packages you need – these commands install specific versions of each package.

Install-Package EPiServer.CMS.Core -Version 7.0.586.1
Install-Package EPiServer.Framework -Version 7.0.859.1
Install-Package Castle.Core -Version 3.1.0
Install-Package StructureMap -Version 2.6.1.0
Install-Package Newtonsoft.Json -Version 4.5.7
Install-Package log4net -Version 1.2.10

Rebuild the solution and you should be back where you started (a working Alloy demo site) and also now set up to use Nuget to update to the latest patch releases. Incidentally I’m not sure why the EPiServer Nuget packages don’t correctly list their dependencies. To me, EPiServer.CMS.Core is dependent on all of the packages listed above. Having these dependencies stated in the nuspec file would simplify the initial installation step, and no doubt help dependency management going forward.

3) Install the Updates from Nuget

Now you’re in a position to see just how easy applying a update is. Open your solution, go to the Nuget package manager console and type:

Update-Package EPiServer.CMS.Core

Voila – all of the latest EPiServer hot-fixes delivered straight into your solution via one command and now ready for you to build / validate and distribute to your client!

Written by mark

March 26th, 2013 at 10:30 am

Posted in EPiServer

Serving EPiServer CMS 6 and Composer over SSL

with 2 comments

It’s often a requirement for enterprise customers to maximise security on their public-facing websites and to request that access to the EPiServer interface is locked down.

With the standard EPiServer CMS there are a number of ways to do this, from removing the edit ui bindings from public facing web-servers to serving the edit mode over https. Forcing the edit ui over SSL largely comes down to just updating your EPiServer configuration (uiUrl and utilUrl) so that they explicitly state that the interfaces should be served over https. EPiServer then will not serve the interfaces over http, any http requests for them will result in a 404, so you can be sure that nobody can get access via an unsecured channel.

Things can get a lot more complicated with a load balanced physical server set-up / enterprise sites or with the addition of EPiServer Composer. In this post I’ll attempt to walk through a few common scenarios and how we’ve managed to overcome them.

Composer over SSL

Lets talk through the following scenario. You have a single front end server, which has an SSL certificate installed directly onto it, and so it listens and responds to requests over port 80 and port 443. You want to force all editing and interaction with EPiServer interfaces to occur over a secure channel. Oh and your editors love creating flexible layouts so you also have Composer installed.

EPiServerSSL-single

Composer adds complication due to the fact that it offers editors the ability to directly edit page content through the view url. For example – when using Composer edit on page mode – you’ll see a URL with the following format in your browser address bar.

http://www.mysite.com/?idkeep=True&DE_VM=4&DE_LNK=13_3404&DE_RND=1734871469&id=13_3404

So now we need to

  • Serve the ui / admin / util paths over SSL
  • Serve Composer on-page editing over SSL

In this case – if you set the uiUrl and utilUrl to force a secure channel in configuration, then all will work as expected when editors navigate around the site using the EPiServer context menus and navigation. However, although editors will be pushed to edit over SSL, Composer on-page edit will still be available over http – but only if they manually change the URL, which most sane people would regard as a ‘tiny’ security hole. The suggestion here is to physically separate your view and edit mode functions into individual installations.

Load-Balanced Composer over SSL

Ok, so lets add another layer of complexity 🙂

We now have multiple front end web-servers, sat behind a load-balancer. The SSL certificate is installed on the load-balancer which listens on port 80 and port 443. The load-balancer performs the encryption / decryption and forwards requests on to the front-end webservers over port 80, but with some additional information added to the internal request to let the web-servers know that this was originally a secure request. You want to force all editing and interaction with EPiServer interfaces to occur over a secure channel and yes, we still have Composer.

In this scenario we can’t just update the EPiServer configuration, as the application never sees https requests. If you try this and set the uiUrl and utilUrl to https:, you’ll find that your edit and admin modes will return 404’s. This is because for every edit and admin mode request; EPiServer checks the request to make sure the full request matches the configuration setting. As the load-balancer has offloaded the SSL, the request as seen by the web-server is a standard http request meaning you’ll end up with a 404 as EPiServer can’t match the request to the configuration.

So out-of the box EPiServer as an application doesn’t handle this situation – but that doesn’t mean it can’t be achieved

IISRewrite to the rescue

IISRewrite is an module for IIS 7+ that allows server administrators the ability to add in powerful rewrite and redirect rules to your website. Think of it as the mod_rewrite equivalent for the Windows stack. This allows you to intercept and change requests very high in the request pipeline, before your application sees them. You have access to the full request so you can write rules based on url, querystring or any http header. For this scenario we are going to use it to force requests onto https and http depending on what path is being requested.

EPiServerSSL-multiple

EPiServer should be configured to accept requests to the ui and util over any communication channel, and then IIS Rewrite is used to ensure that requests are forced into the correct communication channel by returning a http 303 response to the browser, which will then initiate a new request. This is a similar approach that Kjetil Simensen took – with his Secure pages module (available on EPiServer Nuget) though he uses a HttpModule within the application rather than IIS. The advantage, in my mind to using IIS is that you can make this setup environment specific meaning your development and test environments do not have to use SSL and also this gives greater flexibility for dealing with different SSL offload rules.

We need to add the following rules to IIS Rewrite. This can be done through IIS itself – but all this does is update your application web.config, so you can actually include these rules manually within your source control. In this scenario we need to check to see for particular application paths whether the original request was secure or not and if it forms part of the EPiServer interface. The rules need to:

  • Force all requests for the UI to be served over SSL
  • Force all requests for Util to be server over SSL
  • Force all requests for Composer ui elements to be served over SSL
  • Force all view mode requests that contain the Composer querystring parameters (idkeep=true and DE_*) to be served over SSL
  • Optionally force all requests that don’t match the above to be served over http

Our load-balancer offloads all requests and adds an additional http header into the request (SSL=true), so the presence/absence of this header is used to work out whether to force a redirect.

The IIS rules we needed to set up Composer and CMS are listed below. More details on the Xml syntax for IIS Rewrite.

<rewrite>
      <rules>
        <rule name="ComposerOnPage Redirect to HTTPS" patternSyntax="Wildcard" stopProcessing="true">
          <match url="*" />
          <conditions>
                        <add input="{HTTP_SSL}" pattern="true" negate="true" />
                        <add input="{QUERY_STRING}" pattern="*DE_VM=*" />
                        <add input="{QUERY_STRING}" pattern="*DE_LNK=*" />
                        <add input="{QUERY_STRING}" pattern="*DE_RND=*" />
                        <add input="{QUERY_STRING}" pattern="*idkeep=true*" />
          </conditions>
          <action type="Redirect" url="https://{HTTP_HOST}/{R:0}" redirectType="SeeOther" />
        </rule>
        <rule name="Util Redirect to HTTPS" patternSyntax="Wildcard" stopProcessing="true">
          <match url="util/*" />
          <conditions>
                        <add input="{HTTP_SSL}" pattern="true" negate="true" />
          </conditions>
          <action type="Redirect" url="https://{HTTP_HOST}/{R:0}" redirectType="SeeOther" />
        </rule>
        <rule name="Ui Redirect to HTTPS" patternSyntax="Wildcard" stopProcessing="true">
          <match url="ui*" />
          <conditions>
                        <add input="{HTTP_SSL}" pattern="true" negate="true" />
          </conditions>
          <action type="Redirect" url="https://{HTTP_HOST}/{R:0}" redirectType="SeeOther" />
        </rule>
        <rule name="Composer Redirect to HTTPS" patternSyntax="Wildcard" stopProcessing="true">
          <match url="Dropit/Plugin/Extension/UI/*" />
          <conditions>
                        <add input="{HTTP_SSL}" pattern="true" negate="true" />
          </conditions>
          <action type="Redirect" url="https://{HTTP_HOST}/{R:0}" redirectType="SeeOther" />
        </rule>
      </rules>
    </rewrite>

Beware of mixed mode security

When setting up these rules be aware of mixed mode security. Browsers will block any request over an insecure channel when the initial response is secure. This can often be seen through the EPiServer interface as blank tabs / screens. For example, without the Composer On page rule listed above, the Composer tab in edit mode would request the page over http: would would be blocked by the browser. You should take care to include additional rules for any other plugins you may have in your solution – otherwise you may just see a blank screen due to your browser blocking the request. Fiddler / Firebug are good ways of exposing this

Summary

In conclusion, I’ve walked through a more complicated SSL set up for EPiServer Composer and CMS 6 which used IIS Rewrite to force all interactions with EPiServer CMS6 and Composer to be served over a secure channel.

Written by mark

March 25th, 2013 at 2:45 pm

Posted in EPiServer

Using MiniProfiler with EPiServer CMS7

with 4 comments

MiniProfiler is a great tool for allowing in-situ profiling to be performed directly on a production site; by your development team whilst hiding any detailed specific information from a standard end user. It was developed by Sam Saffron who built it (and then open sourced it) to solve real-world profiling issues on StackOverflow.

It’s been around for a while and has already been integrated with EPiServer 6 based sites. However it really comes into its own when you can hook it into application events that contain performance information that you really care about. MiniProfiler already comes with some integration good hooks into the MVC framework allowing you to profile each of your controller action methods, and also some useful hooks into EntityFramework which allow to to see and time any database calls that EF makes for you.

The underlying API improvements in EPiServer CMS 7 allow us to easily integrate the new shinier ASP.NET tools and gain some real value from them. In the case of MiniProfiler – we can use the new EPiServer IContentRepository interface (whose usage replaces the DataFactory singleton) to build a concrete implementation which wraps the standard implementation to provide hooks into MiniProfiler. This means we can easily see what data related calls our EPiServer templates make on screen as the page is delivered. This is a great tool for assessing page performance and cache usage.

POSSIBLE.ProfiledContentRepository

I’ve released a Nuget package that contains 95% of the code you need to see meaningful MiniProfiler output on your CMS7 site.

  • ProfiledContentRepository – an IContentRepository implementation contains MiniProfiler steps. An example of the GetChildren<T> IContentRepository method is shown below.
public IEnumerable<T> GetChildren<T>(ContentReference contentLink) where T : IContentData
{
    string stepName = string.Format("GetChildren<{0}>[{1}]", typeof(T).Name, contentLink);

    using (MiniProfiler.Current.Step(stepName))
    {
        return DataFactory.Instance.GetChildren<T>(contentLink);
    }
}
  • Container initialisation – the ProfiledContentRepository  instance is injected into the EPiServer IoC container via an Initialisation module and then used as the default implementation for all content retrieval
  • Global application event hooks – MiniProfiler is started and stopped on each Http Request by registering against global application begin and end requests events (performed via the init method of an HttpModule).
  • Overridable display logic – You can choose any arbitrary logic to decide how and whether to show the MiniProfiler output to a site visitor. Usually you’d do this via the incoming request IP address or by checking for the presence of a specific Http header. By default the Nuget package will show the output to any Http request from an authenticated user matching the WebAdmin / Administrator roles. This behaviour can be modified by amending the DisplayProfilerHandler.ShouldShow and the DisplayProfileHandler.ShowToUser delegates which you’d likely do on application start up or in an initialisation module. As an example – the following will set the module to only display to me (username mark.everard) when I’m visiting from a specific IP address.

DisplayProfilerHandler.ShouldStart= httpContext => httpContext.Request.ServerVariables["REMOTE_ADDR"].Equals("217.114.90.249");

DisplayProfilerHandler.ShowToUser= httpContext => httpContext.User.Identity.Name == "mark.everard;

Ideally you want to start profiling early and only for users that will see the end information. This is the reason for the multiple delegates where you can set your behaviour as to whether to start profiling (which happens on the global BeginRequest event – that occurs before ASP.NET has worked out whether the request is from an authenticated user) and also on the PostAuthorizeRequest method that works out whether to continue profiling and can contain user specific logic. This is mentioned in more detail in this Stack Overflow post.

For optimum performance when using this module in production you should override the default DisplayProfilerHandler.ShouldStart delegate. By default every request is profiled, and then the results thrown away when we can calculate whether the user is logged into EPiServer.

Installation

To use this – install the POSSIBLE.ProfiledContentRepository package from the EPiServer Nuget feed and remember that you need to add the following line to your MasterPage / Layout file just before the closing body tag. It is this call that actually outputs the profiling information.


@MiniProfiler.RenderIncludes();

miniprofiler-example

Happy Profiling!!

Written by mark

March 14th, 2013 at 12:01 pm

Posted in ASP.NET,C#,EPiServer