Composite IDataRenderingResponseHandler vs Owin Middleware

One of the tricks to create high performing websites is to use caching and in this blog post I am showing how Owin can be used together with Composite C1 to create high performing websites backed by a CMS.

In Composite C1 we have IDataRenderingResponseHandler which can be used to decide if the page should be rendered or maybe redirected. I am using this in an integration package for Microsoft Asp Net Identity, where I for each CMS managed page can set a flag if it require user authorization.

This of cause means I cannot have caching enabled for these pages. Caching is an easy way to use to create high performance websites. A CMS gives you the power to create a dynamic website that can be changed by non-developer end users. When I create websites, I combine these two things and in most cases, there are no problems with this. As soon as we introduce user authorization into the application, then we have to decide how we want to design the application.

To continue using caching, because the heavy part of the website page rendering will come from the CMS dynamic structure, I design my sites around WebApi and simply render pages that ask for the user-personalized content over WebApi. On a project I work on I ran into the issue that the IDataRenderingResponseHandler is running when C1 is rendering the page and if it’s returning cached content it of cause will not be triggered for the request. 

One way would be to in javascript to redirect the user if his session cookies have run out whe asking the WebApi for his profile info, but this means the webpage will be served and if it had data that was supposed to be protected then it is not that secure any more.

OWIN gave me the tools to keep doing it the way I used to do it but actually hooking up some security even for cached pages.

    app.Use((ctx, next) =>
        var path =  ctx.Request.Path;

        // Hook up here and decide if the page should be send to authentication.
        if (!ctx.Authentication.User.Identity.IsAuthenticated &&
            path.Value == "/Azure-Web-Role")
            ctx.Response.StatusCode = 401;
            return Task.FromResult<int>(0);
        return next();

So here I can hook up against the data provider and ask if the requested path is allowed and if not, then set the status code to 401 which will make OWIN start the authorization flow. This way I can continue to have long cache timers on the page that the CMS renders and still serve personalized content.

comments powered by Disqus