Shahed Khan

Implement custom Claim based Authorization in ASP.NET MVC Web Application

shahed — Fri, 05 Feb 2010 06:01:21 GMT

To download the source code please click here

Introduction

Claim-based authorization is a new model of authorization introduced in Windows Communication Foundation. This model addresses more scenarios than the popular role based security model (IIdentity, IPrincipal). This is useful when an application requires complex and fine grained control on expressing access control decisions. Role based security model may not be powerful or flexible enough and is often too coarse when we reach complex scenarios - where custom roles are often necessary to represent different combinations of permissions or rights. For example – if you wanted to build a simple patient list page and wanted to have access control on CRUD operations based on roles you will end up creating several roles to support different combinations of access rights i.e. Administration clerks can only Add and Edit a patient but not Delete. Where the Supervisor can Add, Edit and Delete Patients. However you may want to restrict a Supervisor from certain access rights and then – end up creating custom roles depending on particular use cases. Claim based authorization framework attempts to address these limitations by providing a more generic model capable of addressing heterogeneous credential types, the ability to specify authorization policies through configuration at deployment time, and the flexibility to express arbitrary access control decisions based on the available evidence. .NET Framework starting in version 3.0 introduced a new identity and access-control API and can be found in the System.IdentityModel assembly and namespace.

Some of the terms and concepts that we need to get familiar with when we talk about claim based authorization - are: Claim, ClaimSet and IAuthorizationPolicy.

Claim : A claim is a piece of information that describes an individual right or action applicable to a particular resource. A claim consists of three pieces of information: a claim type, resources and right. The datastructure is represented by a class System.IdentityModel.Claims.Clam.

ClaimSet: A claim set is an enumeration of claims with a common issuer.

IAuthorizationPolicy: Authorization policyis an extensiblility point which allows new claim sets to be added to the context representing the web service or application. Claims are added to an EvaluationContext by authorization policies.

For more information please check “A Guide to Claims-Based Identity and Access Control” and “Building a Claims-Based Security Model in WCF”.

Claims are flexible and can be assigned based on authenticated users or authenticated user’s roles, although claims are guaranteed by a trusted issuer, which has added security benefits. The association between claim and the resources to which it grants rights seems to be more useful as it rarely changes, and the rules for how users and roles are assigned claims can freely change without impacting any authorization logics. For example one can design - Create, Read, Edit, Delete claims for Patients and can assign them to preferred list of users or roles freely.

FictitiousHospital.com

Today we will look at building custom Claim based Authorization in a ASP.NET MVC application. For this discussion I will keep the application requirements simple – we will build a simple patient list page that lists inpatients and outpatients – however when an user is not authenticated the patient list page do not display the user the options to create, edit or delete patients.

Fig 1 : FictitiousHospital.com

To build this application we will use the ASP.NET Membership and FormsAuthentication - to authenticate users. Then we will implement a custom authorization policy (that implements the type IAuthorizationPolicy ) to serve a “Issuer” and the “set of claims” that can be attached to the securitycontext. Finally we will hook up the claim based security model within the ASP.NET MVC by extending different parts of the MVC Framework.

Authentication

The project template of ASP.NET MVC Web Application ships with some basic pages for authentication, e.g. Login, Registration, Change Password etc. including the web.config file configured with ASP.NET Membership provider and FormsAuthentication. This is handy as the application is already configured and ready to use with Authentication in place. Just a change of connectionstring that points to the correct aspnetdb database makes us ready to start Authenticating the users and we can start concentrate on the next step - Authorization.

Fig 2: web.config

Fig 3: FormsAuthenticationService

Authorization

The first thing to identify is to what types of claims make sense for our fictitioushospital.com website. Lets think of claims as permissions that are required to access the features. If we consider patients as resources we may have (CRUD) permissions like Patient Create, Patient View, Patient Edit and Patient Delete. So the possible list of claims may be:

1. Patient Create

Right: http://schemas.xmlsoap.org/ws/2005/05/identity/right/possessproperty

Claim Type: http://schemas.fictitioushospital.com/2010/02/identity/claims/create

Resources: http://schemas.fictitioushospital.com/2010/02/identity/resources/patients

2. Patient View

Right: http://schemas.xmlsoap.org/ws/2005/05/identity/right/possessproperty

Claim Type: http://schemas.fictitioushospital.com/2010/02/identity/claims/read

Resources: http://schemas.fictitioushospital.com/2010/02/identity/resources/patients

3. Patient Edit

Right: http://schemas.xmlsoap.org/ws/2005/05/identity/right/possessproperty

Claim Type: http://schemas.fictitioushospital.com/2010/02/identity/claims/update

Resources: http://schemas.fictitioushospital.com/2010/02/identity/resources/patients

4. Patient Delete

Right: http://schemas.xmlsoap.org/ws/2005/05/identity/right/possessproperty

Claim Type: http://schemas.fictitioushospital.com/2010/02/identity/claims/delete

Resources: http://schemas.fictitioushospital.com/2010/02/identity/resources/patients

To work with these claims in code we define list of representative constants as follows:

Fig 4: Resources

Fig 5: ClaimTypes

We have already established our requirements for claims-based authorization for our fictitioushospital.com and now we are going to write an implementation of type System.IdentityModel.Policy.IAuthorizationPolicy interface (i.e. CustomAuthorizationPolicy). This interface requires us to implement properties, Id of type string, Issuer of type ClaimSet and the Evaluate() method that returns bool.

Fig 6: IAuthorizationPolicy interface

Fig 7: CustomAuthorizationPolicy

The CustomAuthorizationPolicy implements necessary interface. The Id property returns an unique identifier. The issuer property returns ClaimSet describing the issuer associated with this authorization policy, note that we have used issuerName = http://www.fictitioushospital.com/2010/02/issuer here. Finally the Evaluate() method that is the most important part of this implementation is responsible to inspect the claims based on the credentials provided.

Fig 6: Evaluate() method

Here we have written some code that decides to attach Create, Read, Update and Delete claims to the evaluationContext when the user is authenticated otherwise only attaches the Read claim. We can implement different other ways to figure out the associated claims for the particular User.Identity e.g. based on roles or based on predefined access rights that is stored in database or xml.

The hard part is quite done – now we have to hook up this CustomAuthorizationPolicy into our ASP.NET MVC pipeline to start performing claim based authorization. Step 1: to do this we start by defining our custom IUser interface that extends IPrincipal interface and wraps an extra property named “Issuer” of type ClaimSet within, that is intended to carry the Issuer details returned from the CustomAuthorizationPolicy.

Fig 8: IUser interface

Step 2: we implement the User class of our custom IUser interface.

Fig 9: User

Step 3: we implement a custom authorization filter of type System.Web.Mvc.IAuthorizationFilter interface. OnAuthorization() we instantiate our custom User (that implements IPrincipal) using the information obtained from “filterContext.HttpContext.User.Identity”. Then we create a list of AutorizationPolicy and add our CustomAuthorizationPolicy to create a default instance of AuthorizationContext (authContext), this under the hood goes and call the Evaluate() method of CustomAuthorizationPolicy and populates the authContext.ClaimSets. Then we iterate through the authContext.ClaimSets and locate the issuer that we are interested in and assign the issuer to our custom User object. We then replace the HttpContext.User and Thread.CurrentPrincipal with our custom User. Please also note that we keep the customUser in Session() to avoid repeatative calls to retrieve the claimSet on every single request. A ClaimSet may be retrieved from database and this may be an expensive call to perform on every single request, populating it once and storing it in session seems feasible.

Fig 10: AuthorizationFilter

Step 4: we add this custom AuthorizationFilter in the controllers AuthorizationFilters list by extending the ControllerActionInvoker.

Fig 11: CustomControllerActionInvoker

The default implementation of IActionInvoker is ControllerActionInvoker and does quite a bit behind the scene. Firstly it obtains parameter values for the parameters on the action methods using the ModelBinder and then it executes various filters. There are different types of filters:

Authorization Filter – IAuthorizationFilter interface
Action Filter – IActionFilter interface
Result Filter – IResultFilter interface
Exception Filter – IExceptionFilter interface

and out of them Authorization filter is the first set of filters to be executed. This is where our custom AuthorizationFilter will get executed and that will replace the IPrincipal user identity with our custom custom User that we discussed above.

Step 5: we extend the DefaultControllerFactory and implement CustomControllerFactory, that assigns the controller.ActionInvoder to an instance of CustomControllerActionInvoker instead of the ControllerActionInvoker.

Fig 12. CustomControllerFactory

Step 6: we tell our Mvc ControllerBuilder.Current.SetControllerFactory() to use the extended CustomControllerFactory insead of the default DefaultControllerFactory, and we normally do this once during the Application_Start as following.

Fig 13: Application_Start

Step 7: finally we are ready to check for claims during our Action invocation. Consider the PatientController, Index() action that returns list of patients. However this checks whether callers are granted to the Create, Edit and Delete role using the issuer.ContainsClaim() method and populates the PatientViewModel s CanCreate, CanEdit and CanDelete property, and the viewModel object is passed to the View.

Fig 14: PatientController Index() action.

Later on by checking the PatientViewModels properties in the View one can easily decide on what links to display or not.

Fig 15: View

I have mentioned earlier that the association between claim and resources are highly unlike to change frequently. Consider this example where the Create() action demands the PatientClaims.PatientCreate Claim before this allows to create a new Patient, and similar with Update() action where it demands the PatientClaims.PatientUpdate claim. And thus the rules for how users and roles are assigned claims can freely change without impacting any the authorization logics.

Fig 16 Create, Update example

Claims-Based Permission Demands

You can take this further and implement Claims-Based Permission Demands, thus you will be able to write something like this:

[CreatePatientsClaim(SecurityAction.Demand)]
public void Create()

{
//protected code
}

[UpdatePatientsClaim(SecurityAction.Demand)]
public void Update()

{
//protected code
}

[DeletePatientsClaim(SecurityAction.Demand)]
public void Delete()

{
//protected code
}

Permission demands are implemented with the PrincipalPermission or PrincipalPermissionAttribute and relies on the security principal attached to the executing thread to authorize calls. The idea is that when the permission demand is invoked the security principal attached to the request thread checks necessary values. Like with the PrincipalPermission type, you can write your own custom implementation of ClaimsPrincipalPermission that implements IPermission, ISecurityEncodable and IUnrestrictedPermission interface. This article “Building a Claims-Based Security Model in WCF – Part 2” by Michele Leroux Bustamente explains this in great detail.

Conclusion

Here we looked at how to implement claims-based security model in an ASP.NET MVC application. So how all this works in ASP.NET MVC according to the above implementation is,

OnApplication_Start we SetContollerFactory to use CustomControllerFactory.
CustomControllerFactory assigns instance of CustomControllerActionInvoker to the controller.ActionInvoker property of every controller instances.
CustomControllerActionInvoker adds our AuthorizationFilter to the controllers AuthorizationFilters list.
OnAuthorization of AuthorizationFilter is always invoked as the first thing during “InvokeAction()”. This calls the CreateDefaultAuthorizationContext() passing the list of IAuthorizationPolicies, i.e. the CustomAuthorizationPolicy. The CustomAuthorizationPolicy instantiates itself with an unique Id.
The Evaluate method of the CustomAuthorizationPolicy is called and that retrieves the ClaimSet for particular issuer for a particular user.
A custom user is created of type User (that implements IUser –> IPrincipal ). This custom user is assigned to the HttpContext.User and Thread.CurrentPrincipal.
The controller gets the custom user ( of type User – that implements IUser –> IPrincipal ) in its context.
The action methods decides on access rights using the User.Issuer.ContainClaims() method.

Claim based authorization model is not to replace the role based authorization model and in many cases role based authorization may turn out to be more than sufficient. Claim based authorization models definitely supports more complex scenarios and allows fine grained control on expressing access control decision. Thank you for being with me so far and I hope that this discussion will help you in some way during your implementation of claims based security model. Happy coding!

Use IoC slash Dependency Injection framework to manage hierarchical object structure better

shahed — Sat, 23 Jan 2010 21:47:11 GMT

To download the sourcecode click here

Introduction

Recently I have been working with some hierarchical object structures that are a composition of several other nested classes and elements, that we call “template objects”. To give you an idea of this, consider “Patient” class as a container that holds patient demographics in a hierarchical object structure.

Fig: hierarchical template.

These template objects are very robust and flexible, someone can go and design a template like above in a hierarchical structure with unlimited nesting and we have a tool that goes and generates these template objects automatically for us. e.g.

Fig: nested template objects.

Problem

I have been developing some web based CRUD interface pages with these template objects / container classes. However I faced some problem with the hierarchical nature of the template objects. Speaking of the above template as an example, two major problems that slowed down the development are

1. If I wanted to populate current address of the Patient class I had to instantiate several nested classes of the template object and then finally was able to assign the value to the desired address property. e.g.

2. If I wanted to display the “current address” of the Patient to the page, I had to go through all sorts of null checking on several layers of the hierarchical object structure.

As you can realize, that any kind of get and set operation to a nested object turns into a big task for the developers and the more deeper nested the object is in the hierarchy the more codes has to be written to deal with it.

Before I suggest a solution to this problem , lets look at different ways to maintain/represent hierarchical objects in C#.NET.

General class

This is the most common approach that we take, we create different dependent classes in separate physical file under same namespace.

Fig: classes in separate physical files.

However when we auto generate classes from templates there is high chances of class name conflicts. To overcome that scenario we can take one of the following approaches: Namespace separated class or Nested class.

Namespace separated class

In this approach every class can be maintained in separate physical files or all related classes can be dumped in one single physical file. However the key difference of this pattern to the above is every single class gets its own different namespace that also resembles the hierarchy. I made up the Namespace conventions to be the parent class name suffixed by the string “Ns”.

Fig: namespace separated classes.

When classes are stored in separate physical files, there is potential of physical filename conflict of the generated classes. This is easy to solve though, the related classes are sometimes grouped and stored in separate folders.

Nested class

The other approach is to create nested classes like we have seen above in “Fig : nested template objects”. Normally when one class is entirely dependent upon another, we decide to implement it using a nested class. Nested classes are declared within the scope of an existing class and receive special benefits when accessing private and protected members of their parent class.

Inversion of control (IoC) slash Dependency Injection

Speaking about the problem that we identified earlier, here are some thoughts to solve the issues. I have some experiences with Inversion of control (IoC) slash Dependency Injection on test driven developments and I am aware the IoC frameworks provides simplified object creation, especially for hierarchical object structures and dependencies. I looked into this further to come up with a solution. For those who are new to DI and IoC, I would recommend you to read Martin Fowlers article : “Inversion of Control Containers and Dependency Injection pattern”.

In fact any of the following conditions justifies using the DI pattern.

You want to decouple your classes from their dependencies so that these dependencies can be replaced or updated with minimal or no changes to your classes' source code.
You want to be able to write classes that depend on classes whose concrete implementation is not known at compile time.
You want to be able to test your classes in isolation, without using the dependencies.
You want to decouple your classes from being responsible for locating and managing the lifetime of dependencies.

source: http://msdn.microsoft.com/en-us/library/cc707845.aspx

There are lots of IoC containers out there and some of the popular ones are StructureMap, Unity, Ninject, AutoFac, Castle Windsor and Spring.NET.

Solution

So by using the DI, we can inverse the dependencies on the template object classes and make them less coupled. e.g. by getting the PatienDemographics injected as a constructor parameter on the Patient class we can inverse the dependency and now Patient class depends on someone else to pass in the dependency. We can decouple and make this more flexible by declaring an interface for PatientDemographics and then pass the IPatientDemographics instead, something like this.

Fig: refactored Patient class.

We continue to inverse the dependencies for all other template objects in the hierarchy e.g.

Fig : refactored classes.

The next thing to do, is to register all our dependencies in IoC container by passing the container an interface that the dependency implements, and the concrete class that will be instantiated for request of that interface. In other words during the registration we tell the IoC container what and how it should build or find or serve requested services. I will register my dependencies using StructuredMap here.

Fig : structuremap registry.

By default, as long as an object is being created by invoking its constructor function, StructureMap will try to create/resolve/find an object for non-primitive dependency in the requested concrete type. This is known as autowiring, IoC will take care of instantiating all necessary dependent objects automatically. If StructureMap doesn’t know how to find a requested dependency it throws exception. This solves our problem, here is how:

1. If I wanted to populate current address of the Patient class I do not need to worry about instantiatiating several nested classes of the template object, because that will be magically handled by the IoC and I will be able to assign the value to the desired address property with one line of code like the following.

2. If I wanted to display the “current address” of the Patient to the page, I do not need to go through all sorts of null checking on several layers of the hierarchical object structure, because IoC will automatically instantiate all dependent objects. I can go to the desired property directly and display the value when available.

You can see now clearly, how inversing dependencies and use of IoC container improves developers productivity significantly.

Before I finish I must also introduce the Common Service Locator library that contains a shared interface for service location which application and framework developers can reference. The library provides an abstraction over Ioc containters and service locators, which helps developers to use IoC without tying them down to a specific implementation. Currently service locator adapter implementations are available for StructureMap, Unity, Castle Windsor, Sprint.NET, Autofact, MEF and Linfu. The full list can be found here.

I hope this discussion will solve some programming nightmare with hierarchical object structure. Thank you for being with me so far and happy coding.

ASP.NET MVC, ASP.NET Tips: Provide immediate feedback to the browser on Long Running Tasks – using IFrame and web handlers

shahed — Tue, 27 Oct 2009 16:28:13 GMT

to download the source code please click here

The <iframe> tag defines an inline frame that contains another document and is supported in all major browsers.

The <iframe> can be placed anywhere in the document flow. The iframe properties such as height and width can be easily modified by CSS and JavaScript. Data can be passed back and forth between the parent container and iframe using Javasrcipt. The document that is displayed inside an iframe can access the main window by the parent keyword. Iframe can have their own source URL that is distinct from the parent page and we are interested on this feature. We first declare an Iframe in the page and keep it hidden. We then point the Iframe to our preferred web handler, during page load iframe initiate a request to the server and the server start the lengthy task, and flushes state change information. The server flushes the response wrapped inside <script> tag to perform DOM manipulation on the parent container – similar technique that we have seen in one of my post earlier. Here are the steps to follow.

Declare Iframe in the page.
Hide the Iframe.
Point the src of the Iframe to the web handler.
Get Iframe to initiate request from the the browser client to the web server when the page loads.
Get the web handler to flush response on task state changes.
Perform DOM manipulation on the parent container.

Here I have declared two javascript functions in the parent page – “updateContent” and “hide”. “UpdateContent” replaces the data on “ReportDiv” element. “Hide” hides the loader image when lengthy task ends. Then down below on the same page I have declared the iframe tag, pointed the src of the iframe to a regular web handler “JsWrappedDataHandler.ashx”, and used the style elements to hide the iframe. Lets look at the web handler and what is cooking there.

This is a regular web handler and you may be wondering why am I sending 256 dummy bytes. This is a workaround to make IE work properly because IE accepts a message from the server after the first 256 bytes. This technique is handy when we do not know about the message size and we can avoid any unexpected event by sending 256 dummy bytes before sending the original message. Next thing to look at is the script block – where it invokes the javascript functions that we defined in the parent container. Example window.paren.updateContent(data), window.paren.hide(). Finally the server is flushes the response directly to the browser. The Iframe receives the progressive flushed response chunk/script block and executes the javascript code - which invokes the javascript functions from of the parent container and updates the content of of “ReportDiv” element until the task completes. The end user gets immediate feedback on task state changes and do not need to wait until the entire response download. When the task is complete it invokes the hide() function to hide the loader image. This is what it looks like.

Asynchronous web handlers

I discussed a little bit about asynchronous web handlers in earlier post and I promised that I will talk about it later – so I do so. It is recommended to use asynchronous web handlers for long/ lengthy tasks. An asyncchronous web handler implements IHttpAsyncHanddler – this means it implements two additional methods BeginProcessRequest and EndProcessRequest. The idea here is to spawn custom threads by hand to run the lengthy portion of the task and not block important ASP.NET work threads from the threadpool. I have discussed about why we should spawn an additional thread in great length in this post, and I am not going to go through that again here, I am jumping straight in to the implentation of Asynchronous web handler.

This page is exactly same as the first one in this post where I declared 2 javascript function in the parent container such as “undateContent” and “hide”. The only difference is the iframe is now pointing to a different web handler and this time an asynchronous handler.

Here this asynchronous web handler implements the IHttpAsyncHandler. The BeginProcessRequest performs all the lengthy bits inside request.BeginProcessRequest method asynchronously and signals when the task is completed. This executes the EndProcessRequest method. The AsycWebHandlerRequest class is a custom hand written class and I paste the code below.

Here I spawn custom Threads by hand to invoke the LongTask method. Long task has exact same code as we have seen in the regular web handler ProcessRequest method above, except the last line where it signals that the task is complete by invoking requestState.CompleteRequest method. Here the Response.Flush method does all the hard work to notify the connected browser about the task state changes and end user can enjoy immediate feedback from the server. You may be wondering about the AsyncRequestState class. I have used the exact same class during implementation of the Asynchrounous Page and can be found here.

I have indicated earlier that a web handlers is recommended for performance critical web pages. I have done some load tests to compare the result of regular web handler, asynchronous web handler and the asynchronous page that pretty much does the exact same operation. The test result of load tests that I have performed in exact same environment can be found below.

Fig: Load test of Iframe and asychronous web handler that uses custom thread

Fig: Load test of Iframe and regular web handler

Fig: Load test of asynchronous web page that implements custom thread

You can see that the asynchronous web handler that spawns custom thread is the clear winner. And when you compare Asynchronous page with web handler – we see web handler is superior.

Please note that the different techniques that I have been discussing in last several posts is also known as Comet that describe the web application model in which a long-held HTTP request allows a web server to push data to a browser, without the browser expicitly requesting it. However holding a connection open for infinite period has negative impact on browser usability. The problem is the javascript will keep accumulating and the page will have to preserve them in the page itself, resulting in a unbound page size and memory implications – at worst the page becomes totally unresponsive and will crash the browser. These is ok to choose for long task that has a definite end, however we need to be a bit careful when it comes to a “real-time” applications that keeps running for indefinite period. For example an airlines time table,

For a “real-time” application ( i.e. chat application, airline timetable ) a polling / long polling mechanism is more suitable where the server keeps looping for infinite period - produces the latest content and store it in a persistent layer – example a database/file, or in the application memory. The browser polls the latest response periodically, performs DOM manipulation to updates the page – and the user gets to see the latest record. Lets look at the polling techniques in my next post.

ASP.NET MVC, ASP.NET Tips: Provide immediate feedback to the browser on Long Running Tasks – using XMLHttpRequest call

shahed — Tue, 27 Oct 2009 16:23:46 GMT

XMLHttpRequest (XHR) is a DOM API that can be used inside a web browser scripting language, such as JavaScript, to send an HTTP or an HTTPS request directly to a web server and load the server response data directly back into the scripting language. The technique that we are going to discuss here takes advantage of XMLHttpRequest objects readyState == 3 status (Interactive – Downloading) and responseText property to perform DOM manipulation in a browser. Here is how it works

A request is initiated from the the browser client to the web server using the XMLHttpRequest object.
The webserver flushes response during task state changes.
XMLHttpRequest object holds partial data in responseText property when readyState is 3 ( Interactive – Downloading ).
DOM manipulation is perfomed during readystate == 3 to interactively update the web content.

to download the source code please click here

Please note that XMLHttpRequest based technique will not work in all browsers. Microsoft clearly mentions in the specification that - “readyState = 3, some data has been received. responseText is not available. responseBody is not available.” So this will not work in IE. However I found it working in Firefox and Chrome. Here is the code.

Here I have created a XmlHttpRequest object and configured it to perform a GET request to my DataHandler.ashx that I have created earlier. The piece of code that does the magic to notify the browser on state changes is the part where I am updating the content of “ReportDiv” element with req.responseText when req.readyState == 3. The responseText dynamically loads the flushed response and this piece of code updates the content of the browser. Then finally I hide the loader image when the req.readyState turns 4 that means – loaded, all the data has been received. This entire process is initiated by the getData() method which is invoked during the pageload even, but you can do the same on onclick of a button or anchor tag or by raising some other event that suits your need. For a refresher on what is happening inside DataHandler.ashx here is the web handler codes.

The web handler simulates a long running task by putting the Thread to sleep. However it keeps flushing the response when the browser is connected to the server, until the task is complete. Please check my earlier post where I have done detailed discussion on Response.IsClientConnected property, Response.Flush method etc.

You may be wondering that this is still not the perfect solution that we are looking for as responseText is not available during readyState==3 in all browsers, we cannot do much about this however we can implement the IFrame Call that works in most of the browsers. Lets look at that.

ASP.NET MVC, ASP.NET Tips: Provide feedback to the user on Long Running Tasks – using loader image - MS AJAX and JQuery

shahed — Tue, 27 Oct 2009 16:21:39 GMT

It is quite common to display a loader-image or some kind of progress bar image in a browser when the server is busy serving the request. Before we go deep into page streaming techniques with XMLHTTPRequest call and IFrame, lets look into a simple loader icon implementation – the idea is to display “loading” image until the task completes, display the response in the browser when task ends and hide the loader image.

to download the source code please click here

Invoke a long task and display loader image to notify task progress – using MS AJAX

Normally in a ASP.NET page we drop the ScriptManager control, put a reference of the webservice that we want to point to. The Scriptmanager goes and creates necessary proxy class for the webmethods. We can also add static methods to an ASP.NET page and qualify them as web methods and invoke them using javascript. This tutorial shows how to do all these by configuring the ScriptManager easily. However I will play with the Sys.Net.WebRequest class directly here. The Sys.Net.WebRequest provides the script API to make Web request. It becomes handy when we need to partially update a little section of the page and it is quite straight forward to use the Web Request class anyway.

It may look like a lots of code above but when you look closely you find that all I have done is setup a get request to asynchronously invoke my DataHandler.ashx web handler that I created earlier. During page load the “PageLoad” method is called and this initiates the entire process. You can also do the same on the onclick event of an input button or anchor tag or by raising some other events that you prefer. The image that I used for the loader has been generated from this website Ajaxload.info, this website has some nice loader image designs available. You can choose your indicator, background color, foreground color and generate your preferred loader. The webrequest invokes the web handler and the loader image is displayed until the full response is available. I populate the “ReportDiv” element with the completed response data, and hide the loader image with loader.style.display = “none”. There is also some codes above that handles timeout and abort situations.

Invoke a long task and display loader image to notify task progress – using JQuery

The JQuery based implementation of the same above is even more simpler and is done with a lot less coding.

All I do here is I configure HTTP GET request call to my DataHandler.ashx inside the “$(document).ready” function -this function is infact the first thing to learn about jQuery if you are new to JQuery. If you want an event to work on your page, you should call it inside the $(document).ready() function. Everything inside it will load as soon as the DOM is loaded and before the page contents are loaded. If you have not worked with JQuery yet I would strongly recommend to have a look at it. The getData() function makes the HTTP GET call to the web handler and on success I put the response to the “ReportDiv” element. Then I hide the loader icon with style display = “none”;

Thats pretty much it, however this is not a robust solution and I am writing all the post in this series to render realtime states of a task in the browser. When we use this technique all we can display is the loader image to notify users that server is busy processing his/her request – we cannot display any real time update on the tasks state changes to the browser. The MS AJAX and JQuery web request calls do not allow to check XMLHttpRequest s readyState==3 status (will discuss about XMLHttpRequest object in the next post ). The web applications are stateless and request can only be initiated from the client, however XMLHttpRequest or a IFrame call can initiate a parallel request to the server and we can take advantage of that to stream contents to the browser. Lets look at them.

ASP.NET MVC, ASP.NET Tips: Provide immediate feedback to the browser on Long Running Tasks – in Asynchronous ASP.NET pages

shahed — Tue, 27 Oct 2009 16:17:05 GMT

to download the source code please click here

In the earlier post we have discussed little bit about the limited number of worker threads available in the thread pool of ASP.NET and we identified why we should always try to avoid to block those important worker threads. ASP.NET 2.0 introduces Asyn=”true” attribute in the page to handle asynchronous scenarios and under the hood this attribute tells ASP.NET to implement IHttpAsyncHandler in the page. There are more than one ways available in ASP.NET 2.0 and ASP.NET 2.0 (plus) to register asynchronous tasks in the page,

by AddOnPreRenderCompleteAsync method.
by declaring PageAsynTask tasks and register them by RegisterAsyncTask method.

However PageAsyncTask provides some extra flexibility over AddOnPreRenderCompleteAsync method, for example

it offers a timeout option.
allows to register more than one async task.
allows to configure async tasks to be executed in parallel or sequentially
RegisterAsyncTask passes HttpContext.Current to the End and Timeout methods
RegisterAsyncTask allows to pass object state to the Begin methods.

Lets look at how we can implement an asynchronous page to serve our scenario that we are focusing here, that is, to run long tasks asynchronously and at the same time provide immediate feedback to the browser.

Fig: aspx page

Fig: code behind

Here in the above code block I have left the AddOnPreRenderCompleteAsync code commented which can be used alternative to PageAsyncTask object & RegisterAsyncTask method. I have registered a PageAsyncTask task using RegisterAsyncTask method. The “task” object is configured to point to – BeginAsyncOperation, EndAsyncOperation and TimeoutAsyncOperation functions. The BeginAsyncOperation does all the lengthy bits inside request.BeginProcessRequest() method and signals when completed, this executes the EndAsyncOperation method. However if the lengthy task is not completed within the timeout period, the TimeoutAsyncOperation executes. Lets look at the AsyncRequest class now.

The most important thing to note here in the above piece of code is, I spawn an additional custom thread by hand and I execute the lengthy bits i.e. the “Process” Method in the custom thread. The Process method simulates the lengthy task by putting the thread to sleep. However note that the Response.Flush() does the magic to notify the connected browser about the task state immediately. It is a good idea to always check the Response.IsClientConnected property we discussed this in length in one of our earlier post.

As soon as the lengthy task completes I call the CompleteRequest method of the requestState object.

The CompleteRequest singnals that the asynchronous task is complete and it invokes the the callback method if available. In this example the callback invokes EndAsyncOperation method that we have configured in our PageAsyncTask object.

You may be wondering why I had to spawn a custom thread to run the lengthy operation where we can simply use asynchronous delegate invocation. You must know that Delegate.Invoke consumes worker thread from the ASP.NET thread pool. Even though the page releases a worker thread into the pool but immediately that thread ( or another worker thread ) is again taken from the thread pool. Now this precious thread is occupied until the long task finishes hence you gain nothing rather add overhead of switching thread from the pool.

Fritz Onion in his popular article “Use Threads and Build Asynchronous Handlers in Your Server-Side Web Code” mentioned the same, “Asynchronous delegate invocation completely defeats the purpose of building an asynchronous handler because it draws from the same process-wide CLR thread pool that ASP.NET uses to service requests. While the primary request thread is indeed returned to the thread pool, another thread is taken out to perform the asynchronous delegate execution, which means that there is a net gain of zero threads for servicing additional requests, rendering the handler useless. You will run into the same problem if you use ThreadPool.QueueUserWorkItem to perform the asynchronous request processing because it also draws threads from the same process-wide CLR thread pool”.

Jeff Prosise also quoted him in his article by saying “Asynchronous delegates, are counterproductive in ASP.NET applications because they either steal threads from the thread pool or risk unconstrained thread growth. A proper asynchronous page implementation uses a custom thread pool, and custom thread pool classes are not trivial to write.”

He also warned about it in his conclusion “A final point to keep in mind as you build asynchronous pages is that you should not launch asynchronous operations that borrow from the same thread pool that ASP.NET uses. For example, calling ThreadPool.QueueUserWorkItem at a page's asynchronous point is counterproductive because that method draws from the thread pool, resulting in a net gain of zero threads for processing requests”.

After all these warnings if you were still implementing the frequently recommended asynchronous delegation invocation ( unfortunately, most of the google search result on this topic of asynchronous programming in ASP.NET will lead to an implementation of asynchronous delegation ) it would look something like this:

I do not want to discuss about delegate invocation because it completely defeats the purpose of implementing Asynchronous pages. I have done some load testing on the above two implementations and found the following result:

Fig: Load test result of asynchronous handlers with a delegate.

Fig: Load test result of asynchronous handler with custom thread.

Clearly we see that we gain significantly on asynchronous handler that uses custom thread in both cases,

requests/sec_total and
avg. Respons_Total.

I got distracted a bit from our original subject matter again, but it was worth doing this one. I have already discussed here how we can run long running task asynchronously and how to provide immediate feedback to the connected browser immediately. In this post and previous posts I was implementing solutions by taking advantage of ASP.NET page and web handlers however we can also give immediate feedback to clients using MS AJAX, JQuery, XMLHTTPRequest, IFrame etc. in ASP.NET pages. Lets look at them one by one.

ASP.NET MVC, ASP.NET Tips: Provide immediate feedback to the browser on Long Running Tasks – by streaming regular ASP.NET page

shahed — Tue, 27 Oct 2009 16:13:06 GMT

Here in this series of post I am discussing few techniques to give client instant feedback on task progress in ASP.NET page. In the previous post I have discussed about displaying task progress - using regular handler, here I will discuss how to do the same in standard asp.net page.

to download the source code please click here

Display task progress – in standard asp.net page

In this technique we write some regular ASP.NET script in the page itself, that performs streaming to the original page response directly. We put the lengthy task related code in the page and keep flushing the response when task state changes. The data is pushed to the the pages outgoing stream and the browser immediately displays the output. The connection to the browser is kept open until the task is complete.

You see above I have written a regular ASP.NET page with some C# scripts that simulated a long running task by forcing the thread to sleep. However before the thread goes to sleep it Flushes the response using Response.Flush method. I discussed about the Flush method in earlier post. It basically facilitates to send buffered output to the browser immediately. The other thing to note here is the the Response.IsClientConnected property which indicates the server whether the browser is still connected or not. The Response.IsClientConnected property can determine if the browser is still connected. So when we perform a lengthy operation it is a good idea to periodically test whether the browser is still connected.

You may have already noticed that I am writing embedded javascript codes that manipulates the DOM. In this case this the ReportDiv elements innerHTML is assigned to latest flushed response. However to keep this example simple, I have been flushing the “report” string over and over again to reflect the changes in the browser and the same data is sent across the wire over and over. This may not be a good idea when you are flushing out a large report with 1000 records. You can reduce the amount of response traffic just by sending the progressive latest content only. To do this you will need to change your DOM manipulation code to perform append instead of replacement. Something like below.

Note that I have changed the codes to flush progressing latest content only, I have also modified the rendered javascript codes that is now appending latest flushed content to the existing content instead of replacement.

The above example is serving the long task in a regular synchronous manner however It is a good idea to implement long running tasks asynchronously, lets look at that in the next post.

ASP.NET MVC, ASP.NET Tips: Provide immediate feedback to the browser on Long Running Tasks – using regular web handler

shahed — Tue, 27 Oct 2009 16:10:17 GMT

As an ASP.NET developer we frequently deal with long running tasks for example:

Making long-lasting webservice calls.
Making prolonged calls to database that runs complex queries.
Do lengthy file operation
Calling remote objects etc.

When the server is busy performing the lengthy time consuming task/tasks, the poor user has to wait for the response. The most common technique used to interact with user is to display a loader icon or show some kind of progress bar on the page until the task is complete. However we can provide user immediate feedback of the task progress/state while the task is running in the Server and make the page more interactive/informative.

Here we will discuss several techniques to give end user instant feedback on the browser about task progress in ASP.NET pages.

such as display:

task progress - using regular web handler.
task progress – in standard ASP.NET page.
task progress – in asynchronous ASP.NET page.
task progress - using JQuery.
task progress - using MS Ajax.
task progress - using XmlHTTP RequestState.
task progress - using IFrame and regular web handler.
task progress - using IFrame and asynchronous web handler.
task progress - by polling a webservice. / web handler

to download the source code please click here

Display task progress using regular web handler:

This is very easy to code, all we need to do is write a regular web handler that runs the long running task and we have to keep flushing the response when state changes, in other words we decide to flush when the task reaches certain stage. The data is pushed to the the outgoing stream and the browser immediately displays the output. The connection to the browser is kept open until the task is complete.

We have created a regular web handler that inherits from IHttpHandler and simulated a long running task by forcing the thread to sleep. However before the thread goes to sleep it Flushes the response using Response.Flush() method. The Flush method sends buffered output immediately. Normally all of the response is sent to the browser only when page completes its processing. This may be a issue for a long running task as the end user will not see anything until the page is complete. The Flush method comes handy in this situation and can send buffered output periodically to the browser. Imagine you will have to display 500 records and you can flush the buffer every 20 records until it is complete. The good thing of doing this is – user can see some data immediately, visualize the progress of the report and the server memory is also released on every Flush operation.

One more thing to note is the Response.IsClientConnected property which indicates the server whether the browser is still connected or has already left. A very common scenario is user starts the long expensive task but decided to close the browser before the task is complete. When a browser requests the page from the server but does not wait for the entire page to be downloaded, the server continues to process the request, wasting CPU cycles. The Response.IsClientConnected property can determine if the browser is still connected or not. So when we perform a long task it is always a good idea to periodically test whether the browser is still connected or not.

A web handler file works just like a aspx page and can be directly browsed via a browser. The web handler above, returns response type text/html and we have pointed an anchor tag to the web handler. Please note a web handler is recommended for a performance critical web page.

I have started with a regular synchronous web handler, however it is recommended to use asynchronous web handlers that implements IHttpAsyncHandler for long running tasks. ASP.NET has limited number of threads in the thread pool and a normal synchronous page holds on to the thread for the duration of the request, and this thread is prevented to be used to process any other request during that period. As a result the thread gets stuck until the lengthy request is complete. If all the threads are stuck doing lengthy tasks the subsequent additional requests starts to queue up and when the queue fill up ASP.NET starts spitting 503 “Server Unavailable” errors.

ASP.NET provides a neater solution to this problem via Asynchrounous web handlers that implements the IHtttpAsyncHandler. The interface suggests to implement two additional methods BeginProcessRequest method and EndProcessRequest. The idea is to spawn an additional thread by hand in response to BeginProcessRequest, then perform the lengthy task in this additional thread and notify when the task is complete so the worker thread can return a response to the user. We will look at Asynchronous web handlers in a later post in more details. Lets continue to look at other techniques now.

Microsoft WebsiteSpark – Receive Windows Web Server and SQL Server Web Edition at no cost to host new websites

shahed — Fri, 25 Sep 2009 03:37:15 GMT

Now help is on the way in the form of Microsoft WebsiteSpark, a program announced today that will empower Web site design and Web application development firms with 10 or fewer employees. WebsiteSpark provides development tools, production licenses for server products, technical support, business development support, and access to the expertise and services of Microsoft’s community of partners and hosters.

visit http://www.microsoft.com/web/websitespark to learn more

ASP.NET, ASP.NET MVC Tips: JSON Handler, Aspx template, Asynchronous JQuery treeview with ashx generic handler and many more.

shahed — Sat, 22 Aug 2009 19:05:07 GMT

In my previous blog post, I have discussed about how to get asynchronous JQuery treevew to work with ASP.NET Webservices, and we identified that, to make a successful ASP.NET webservice call using JQuery the request must be POST request, the content type of the request must be “application/json; charset=utf-8”, and the data parameter of the the $.ajax() method must be passed as a string. We also looked at the tweaks that we need to do to the jquery.treeview.async.js file to get that working.

However I found the JQuery, $.ajax() method can consume JSON objects straightway from the ASP.NET Generic Handler (ashx) that can be designed to serve a JSON response. If you are using ASP.NET MVC framework you will find that $.ajax() can also consume JSON response without hassle from MVC controller actions that returns a JsonResult. I will demonstrate both scenario with my FictitiousWebsite.com.

Fig: FictitiousWebsite.com

Lets look at the ASP.NET MVC Fictitious website application first,

ASP.NET MVC Application

I have put together two classes (TreeService, TheTreeNode) that generates story categories and subcategories as seen in the screenshot above - [categories: “.NET, ASP.NET MVC, AJAX, ADO.NET”, subcategories: “Latest articles, Forum post”]. The TreeService class returns story catetories and subcategories as List<TheTreeNode>.
Then I have designed an MVC controller action to return JsonResult. This serves the Jquery treeview control with the list of story categories and subcategories as JSON response.

I have used “d” variable here to replicate the security feature that has been added to ASP.NET 3.5 JSON serialization, you will notice the JSON response is encapsulated within a parent object to address a nasty vulnerability. You can read more about this vulnerability that Phil Haack has discussed in this post “Json Hijacking”. Encapsulating the JSON response results the following response .
The I have created a View - “LatestStories.aspx” that hosts the JQuery treeview control.

Note that , the treeview control is communicating to my MVC controller discusssed in previous step, through this URL, “/Home/GetStoryList”. You will also notice that I have decoraded a fileClick event for the treeView. When user clicks the subcategories, it asynchronously/on demand gets the relevant list of stories from this URL “/Home/Stories” and renders to the right side panel. This fileclick event do not ship with treeview out of the box, I had to inject 2 lines of code to the original “jquery.treeview.async.js” file to get this happening.
Finally I decorated a aspx template - “Stories.aspx” that serves the necessary html content for the right side panel.

I prefer using templates as aspx files, as I can take full advantage of the intellisense and design support of the Visual Studio. Plus I have the entire ASP.NET MVC framework to back me up to produce and render dynamic contents on demand.

It is very straight forward to consume JSON response in the ASP.NET MVC framework, however the same is not as easy when we deal with ASP.NET Webservices as discussed in my previous post. ASP.NET Webservices is not the only way we can serve JSON response, lets look at how we can design a ASP.NET Generic Handler (ashx) to serve the same. Plus you will also find in a moment that ashx can be more easily consumed by the JQuery $.ajax() method.

ASP.NET 3.5 Website

I have created an exact replica of the FictitiousWebsite.com in an ASP.NET 3.5 website project. This website project has exact same files as the ASP.NET MVC application, with very minor differences.

Here look at the ASP.NET solution explorer snap to get a quick rundown of the similarities and the differences.
The (TreeService.cs, TheTreeNode.cs) files are exactly same as before and generates list of story categories and subcategories.
The ASP.NET Generic Handler (ashx) file “GetStoryListJsonHandler.ashx” serves JSON response to the Jquery treeview control with the list of story categories and subcategories.

You may already recall that we have written similar code in the MVC controller that was invoking the TreeService and returning JsonResult. I have decorated this Generic Handler (ashx) in the similar way. Note I have defined the ContentType = “application/json”, and serialized the data with JavaScriptSerializer. I have also used the “d” variable to replicate the security feature that has been added to ASP.NET 3.5 JSON serialization as before. This results exactly same output as we have seen in the MVC framework earlier. The best part is JQuery $.ajax() method can consume this without any hassle as we have faced earlier to communicate to the ASP.NET Webservice method.
The “LatestStories.aspx” hosts the treeview control, the only difference you will note here is it now communicates with the ASP.NET Generic Handler (ashx) file, and the fileClick communicates to the “Stories.aspx” template.
The “Stories.aspx” file (template) serves the necessary html content to display the list of stories to the right side panel. This page is now backed up by the ASP.NET web forms framework, WYSIWYG designer support in Visual Studio and allows to render dynamic contents easily.

Conclusion

We have discussed, how we can serve JSON response in both ASP.NET MVC and ASP.NET 3.5 website framework. We have identified that consuming a JSON response from ASP.NET Webservice requires some extra steps in the JQuery world, we have demonstrated an alternative approach to serve JSON response using Generic Handler (ashx) and found it easier to consume via JQuery $.ajax() method. While designing the JSON response we used “d” variable to replicate the security feature that has been added to ASP.NET 3.5 JSON serialization. We also looked at rendering dynamic content asynchronously on demand, and identified the advantage of aspx templates as it can be designed using the WYSIWYG designer, intellisense, compilation, dubug, sourceview, splitview, codebehind and all the features of Visual studio and the the ASP.NET framework.

The ficitiouswebsite.com demonstrates everything that we have discussed above and is available to

download here

Thank you for being with me so far, Happy Coding.

ASP.NET Tips : Getting asynchronous JQuery treeview to work with ASP.NET Webservices

shahed — Fri, 10 Jul 2009 13:09:01 GMT

Recently I had to display some hierarchical data in a treeview. I looked around and found JQuery treeview can transforms an unordered list into an expandable and collapsable tree, and supports both location and cookie based persistence.

Fig: JQuery Treeview

As I was dealing with a large amount of data I needed something that will allow me to navigate through the data asynchronously, and I found jQuery Treeview fits well for my purpose. I found this demo of Lazy Loading Tree and I needed to implement similar functionality where the JQuety Treeview communicates to a ASP.NET Webservice.

Problem 1: Unfortunately the codes that ships with the demo do not work with ASP.NET Webservice out of the box. First of all if you have downloaded the TreeView plugin from this link http://bassistance.de/jquery-plugins/jquery-plugin-treeview/ you will notice the "jquery.treeview.async.js" file uses $.getJSON method to make AJAX calls to the server. But this is no good for ASP.NET webservice or WCF which expect JSON POST , this function is only useful for simple JSON results returned from arbitrary services.

Problem 2: However if you download the jquery.treeview.async.js from http://view.jquery.com/trunk/plugins/treeview you will notice the $.getJSON function is commented and an alternative $ajax() method has been used.

but this one is still not good for ASP.NET Webservice calls, I am explaining this in a moment.

There are several options available in JQuery to make AJAX calls to the server. They are
1. $.ajax(opt),
2. $(sel).load(url,data,callback)
3. $.get(url,data,callback,type)
4. $.post(url,data,callback,type)
5. $.getJSON(url,data,callback)
6. $.getScript(url,callback)

The complete list of JQuery AJAX "Requests" and "Event" based functions are all listed here. However to get JQuery working with ASP.NET Webservices we should be interested with $.ajax(opt) function, a low level Ajax function which offers to create any kind of Ajax request. This allow us to configure Ajax request with a set of key/value pairs, and all options are optional. We should be aware that ASP.NET AJAX 1.0 includes a number of default settings and built-in features to prevent from JSON hijacking attacks, ASP.NET AJAX webmethods do not enable HTTP GET requests by default. To make a successful call to the ASP.NET webservice using JQuery we need to make sure that the request must be a POST request, and the request's content-type must be: "application/json; charset=utf-8. By now you have already realized that the above $.ajax() call do not fit any of these two requirements. So I attempted to fulfill these requirements and passed more option paramameters as part of the $.ajax() call.

Problem 3: I modified the script to fit the requirements
- the request must be a POST request
- the request's content-type must be: "application/json; charset=utf-8

However this did not work either. now I started facing another problem, "Invalid JSON primitive: root."

After googling on this issue for a while I found, as the data parameter is a valid JSON object, calling the webservice in this way do not throw any exception, but it also do not produce the desired result either. Instead of passing the data JSON object to the webservice, JQuery automatically serializes and sends it as root = source.

The solution is to make sure that we pass data parameter as a string instead of a JSON object. Encosia.com has a very good post on this subject "3 mistakes to avoid when using JQuery with ASP.NET AJAX", a must read. Finally I adjusted the script as follows and it started working as desired.

Conclusion

I have discussed how to get JQuery treeview working with ASP.NET Webservice. Out of the box treeview ships with "jquery.treeview.async.js" file that is not compatible with ASP.NET Webservices or WCF. To make a successful call to the ASP.NET webservice using JQuery we need to make sure
- the request must be a POST request, and
- the request's content-type must be: "application/json; charset=utf-8.
- the data parameter of the $.ajax() method must be passed as a string.

I hope this will save you some time. Thank you for being with me so far.

ASP.NET MVC Tips: 301 Redirect non-www versions of URL to www.

shahed — Mon, 18 May 2009 13:50:30 GMT

Search Engine Optimization guides, recommends to have one version of a URL of the same content. Search engines may pickup www and non-www versions of URL as 2 separate URLs, i.e. http://xyz.com/page1 may be considered different to http://www.xyz.com/page1. It is a good idea to pick on of these URLs as preferred and use 301 redirects to send traffic from the other URLS to the preferred URL. Today we will pickup www version of URL as our preferred URL and look at how we can redirect the non-www version of the URL to our preferred URL structure using ASP.NET MVC.

We can achieve the above by writing a custom handler that extends from the MvcHandler. We are basically interested in the ProcessRequest method where we can get hold of the non-www version of the URL to replace it to the www. version of URL.

    public class The301GlobalHandler : MvcHandler
    {
        public The301GlobalHandler(RequestContext requestContext) : base(requestContext) { }

        protected override void ProcessRequest(HttpContextBase httpContext)
        {
            //We do not want this handler to process local requests
            if (httpContext.Request.IsLocal)
                base.ProcessRequest(httpContext);
            else
                ProcessExternalRequest(httpContext);
        }

        private void ProcessExternalRequest(HttpContextBase httpContext)
        {
            bool urlChanged = false;
            string url = RequestContext.HttpContext.Request.Url.AbsoluteUri;
            //Check for non-www version URL
            if (!RequestContext.HttpContext.Request.Url.AbsoluteUri.Contains("www"))
            {
                urlChanged = true;
                //change to www. version URL
                url = url.Replace("http://", "http://www.");                    
            }
            ProcessExternalRequest(url, urlChanged, httpContext);
        }

        private void ProcessExternalRequest(string url, bool urlChanged, HttpContextBase httpContext)
        {
            if (urlChanged)
            {
                //mark as 301
                httpContext.Response.Status = "301 Moved Permanently";
                httpContext.Response.StatusCode = 301;
                httpContext.Response.AppendHeader("Location", url);
            }
            else
                base.ProcessRequest(httpContext);
        }
    }

The above code is self explanatory, we are checking if the Request is local or external, we are only interested on external URLs. Next we check, whether the RequestContext.HttpCOntext.Request.Url.AbsoluteUri contains a "www" or not. If it do not contain a "www" we go and inject a "www" to the URL to convert the non-www version of URL to a www. version URL. Then we mark the previous response to a 301, which indicates that the previous URL has been permanently removed and all future requests should be directed to the given new URL.

We have developed our core handler above, however we need a wrapper IRouteHandler class to get the above The301GlobalHandler to work within the MVC Framework. This wrapper class is responsible to return an instance of the The301GlobalHandler.

    public class Route301GlobalHandler : IRouteHandler
    {
        public IHttpHandler GetHttpHandler(RequestContext requestContext)
        {
            return new The301GlobalHandler(requestContext);
        }
    }

We have got our Route301GlobalHandler ready, now we need all of our requests to go via this handler instead of the default. One easy way to do this, is to iterate through the route collection and assign them to this Route301GlobalHandler during the Application_Start().

    protected void Application_Start()
    {
        RegisterRoutes(RouteTable.Routes);
        Route301Global.ReAssignHandler(RouteTable.Routes);
    }

    public static class Route301Global
    {
        public static void ReAssignHandler(RouteCollection routes)
        {
            using (routes.GetReadLock())
            {
                AssignRoute301GlobalHandler(routes);
            }
        }

        private static void AssignRoute301GlobalHandler(IEnumerable<RouteBase> routes)
        {
            foreach (var routeBase in routes)
            {
                AssignRoute301GlobalHandler(routeBase);
            }
        }

        private static void AssignRoute301GlobalHandler(RouteBase routeBase)
        {
            var route = routeBase as Route;
            if (route == null) return;
            if (route.RouteHandler.GetType() != typeof(Route301Handler))
                route.RouteHandler = new Route301GlobalHandler();
        }
    }

Note, if you have other custom RouteHandler in your application, you will need to tweak this code, I am assuming all routes that will be mapped in the RegisterRoutes(RouteCollection routes) method uses the MvcHandler.

Conclusion

We have identified keeping one set of URL is important for SEO. Then we have looked at how we can 301 redirect non-www version of URL to www. version URL in ASP.NET MVC. Hope this saves you some time and thank you for being with me so far.

ASP.NET MVC Tips: Form POST, TryUpdateModel, unit test, Moq

shahed — Fri, 15 May 2009 12:52:51 GMT

Recently I have started playing with the Moq (pronounced "Mock-you" or just "Mock") a Mocking Library for .NET Developers, that takes full advantage of .NET 3.5 (i.e. Linq expression trees) and C# 3.0 features. Here in this post I will discuss how I have used the TryUpdateModel method in the Form POST scenario and also share how I have written a test case using Moq mocking library to deal with the TryUpdateModel<TModel>(TModel model) method of the ASP.NET MVC controller.

I have a very simple user interface, that allows user to enter data and submit, to add a new "User".

My View Page is:

and my "Action" is

You may have already noticed that I have decorated my action without any parameters, and my POST related codes are executed by checking the request type.

if (Request.RequestType == POST)
{
//code
}

As I have no parameters in my CreateUser(), I did not need to create separate action with AcceptVerbs("GET") and AcceptVert("POST") attribute. I have created an empty instance of MembershipCreateViewModel object and passed it to the TryUpdateModel() method to get the values of the posted form into my viewmodel object. MVC framework takes care of the rest and populates the viewModel with the desired values. Also note the RedirectToAction() method has been on success, it is very important to perform this client - redirect. It will ensure that the form does not resubmit, and the user will never see a prompt like this, if he hits the browser refresh button.

My MembershipCreateViewModel class is as follows,

I did not prefer passing four parameters to my CreateUser() Action such as,

[AcceptVerbs["POST"])
CreateUser(string username, string email, string password, string confirmPassword)
{
//code
}

instead I kept the method simple by using the MembershipCreateUserViewModel to communicated between the Controller and the View.

This is all good, but by now you may be wondering how would I test this Controller>Action. Lets explore that part. Here I will demonstrate my TestCase using the Moq framework, but you can do the same using other popular mocking frameworks like Rhino Mock, NMock, NMock2, NUnit.Mocks, EasyMock, TypeMock etc, or even with plain vanilla C# code. First of all I will need a FakeHttpContext to interact with my Controller from the test environment.

It is very straight forward to create a mock of a class or interface in Moq, I have created mocks of HttpContextBase, HttpRequestBase, HttpResponseBase, HttpSessionStateBase, HttpServerUtility above and decorated methods and properties that I use in my test cases using the Setup and SetupGet method that is available in the Moq library.

Note how easily with couple of lines of code I have a mockup of the HttpContextBase. The Mock<T> allows creation of custom value matchers that can be used on setups and verification, completely replacing the built-in It class with our own argument matching rules.

var httpContext = new Mock<HttpContextBase>();
var request = new Mock<HttpRequestBase>
httpContext.Setup(ctx => ctx.Request(request.Object);

This above code snippet is creating mock instances of HttpContexBase and HttpRequestBase classes, and then also setting up that httpContext.Request will return the mock instance "request".

Now lets look at how I have used this mock httpContext in a test case.

I have created a test case here that tests our CreateUser() action. Note I have created an instance of the ControllerContext and passed the httpContext mock object as a parameter of its constructor. After that I have assigned this instance ( context ) to the controller.ControllerContext property.

The Mock.Get() method is interesting it can retrieve a mock object for the given object instance. Here I have retrieved the request object and have modified it further. I have setup so that the request.Form returns NameValueCollection. You may be wondering why did I pass NamValueCollection. You may recall that I have used the TryUpdateModel() method in my action to get the form values into our viewmodel, and if you look what is happening under the hood of TryUpdateModel() method you will find that, "Form" is of type System.Collections.Specialized.NameValueCollection and a member of System.Web.HttpRequestBase, and

the internals of TryUpdateModel() iterates through each item of the ContollerContext.HttpContext.Request.Form object and populates the matching properties of the viewmodel using reflection. The above code snippet from the ValueProviderDictionary class where we see that the keys are being read from the Form object to populate a dictionary.

Conclusion

Here in this post I have discussed a Form POST scenario and I have decorated my action method without any parameters as by default TryUpdateModel method looks at the submitted Form object and attempt to assign it to the viewmodel object that we pass. I have also demonstrated how I have used the Moq library to create fake/mock objects for my testcases, how I have setup some fake methods and properties. I have also demonstrated the handy Mock.Get method that can retrieve a mock object from a given object instance and allows us to modify the mock object further. Thank you for being with me so far and I hope this helps.

ASP.NET MVC tips: Routing Engine to aid SEO / 301 Redirect / Tracking

shahed — Fri, 13 Feb 2009 18:03:14 GMT

Routing Library resides in the System.Web.Routing Namespace of the .NET Framework 3.5, which provides us the flexibility to use URLs that has no mapping to a physical file. This means ASP.NET MVC framework provides flexible URL mapping engine and enables us to write SEO (Search Engine Optimization) friendly URLs with very little effort. No one can deny the importance of SEO, to be successful in search based marketing. What better way to analyze a business than from what customers are looking for on the Internet through keyword research. SEO is the way to go.

SEO friendly URL Format for an e-commerce application may be
/Products/List/ProductCategory
/Products/Detail/ProductName

URL Example
/Products/List/CareCare
/Products/Detail/MiracleCarDuster

In ASP.NET MVC world the URL Routing System maps the incoming URLs to the relevant Controller and Action, in the above example our Contoller is Products and Action is List or Detail. We normally go and define a Route object and add it to the RouteCollection and register the RouteCollection during Application_Start(). Out of the box System.Web.Mvc library ships with the RouteCollectionExtensions which allows us to define routes easily using the the different overloads of MapRoute method.

Example:

public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

           routes.MapRoute(
                "Default",                                              // Route name
                "{controller}/{action}/{id}",                           // URL with parameters
                new { controller = "Home", action = "Index", id = "" } // Parameter defaults
            );

}

If you look under the hood you will find, a Route object is created and added to the RouteCollection.

Route route = new Route(url, new MvcRouteHandler()){};
.....
.....
routes.Add(name, route);

note that "MvcRouteHandler" have been passed as a parameter by default, when we use the routes.MapRoute() method. The overloads of MapRoute() extension methods are just helper methods to make things easy for us, it is not mandatory that we will have to always use this. We can define a Route object in plain .NET code and assign necessary properties to it, we can also pass our preferred IRouteHandler. This gives superb flexibility with handling URLs. For instance In a practical world of web marketing / search marketing we always need to support Legacy URLs. In the web marketing world ad hoc campaigns are launched, and what may have worked last week may not work this week any more, as a result the URL structure changes frequently and we face the need to start redirecting to the new URLs.

On Top of that during this transformation of URLs we need to implement "301 Moved Permanently" redirections, which means the previous URL has been permanently removed and all future requests should be directed to the given new URI. Handling this scenario has become very easy with the Routing Engine. All we need to do is add a new Route or modify the existing Route to fit our need. Matt Hawley has an excellent post on Legacy Url Routing which describes how to route existing aspx file based URLs to the appropriate MVC Controller and Action. This article also gives directions on how to implement custom Route and custom RouteHandler.

public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

           routes.MapRoute(
                "Default",                                              // Route name
                "{controller}/{action}/{id}",                           // URL with parameters
                new { controller = "Home", action = "Index", id = "" } // Parameter defaults
            );

routes.Add("", new LegacyRoute(
    "Users/Login.aspx",
    "Login",
    new LegacyRouteHandler())); // Defined a Custom Route class and have passed a custom IRouteHandler.

}

As you can see in the above code, how easily we can add a custom route and pass a custom IRouteHandler (in this case LegacyHandler).

Tracking - is another common task performed, we want to track everything, every single clicks a consumer performs on the site. This has also becomes easy in the world of ASP.NET MVC. By design we define separate actions for each functionality and we Route to the Controller - Action to get anything done. So tracking would be a viable option to do centrally just before creating the Controller object or just before delegating to the Action.

You will notice the implementation of IRouteHandler requires to implement only one method "GetHttpHandler" which returns a IHttpHandler

public interface IRouteHandler
{
IHttpHandler GetHttpHandler(RequestContext requestContext);
}

You will find the MvcRouteHandler implements IRouteHandler like this

public class MvcRouteHandler : IRouteHandler {
        protected virtual IHttpHandler GetHttpHandler(RequestContext requestContext) {
            return new MvcHandler(requestContext);
        }

}

The real delegation of a Route to a Controller and Action happens in the ProcessRequest(HttpContext context); method of the MVCHandler class which is the implementation of IHttpHandler. The ProcessRequest(HttpContext contxt) method may be a be a good place to centrally control tracking in one of our custom Handlers. The implementaiton of MVCHandler is as follows, where you can see how a controller is created by the IControllerFactory factory, and then Execute() method is called. We can do our tracking somewhere before calling the Execute() method.

protected internal virtual void ProcessRequest(HttpContextBase httpContext) {
AddVersionHeader(httpContext);

// Get the controller type
string controllerName = RequestContext.RouteData.GetRequiredString("controller");

            // Instantiate the controller and call Execute
            IControllerFactory factory = ControllerBuilder.GetControllerFactory();
            IController controller = factory.CreateController(RequestContext, controllerName);
            if (controller == null) {
                throw new InvalidOperationException(
                    String.Format(
                        CultureInfo.CurrentUICulture,
                        MvcResources.ControllerBuilder_FactoryReturnedNull,
                        factory.GetType(),
                        controllerName));
            }
            try {
                controller.Execute(RequestContext);
            }
            finally {
                factory.ReleaseController(controller);
            }
        }

Did you know, Routes in the ASP.NET Mvc are matched and executed on a first match bases! It may be important to order the routes so that the correct pattern is matched first before a more general pattern matches and executes it. It is sometimes hard to figure out which particular pattern will be caught first when we have a lot of routes, ASP.NET Routing Debugger comes in to rescue, Phil Hack has put together this nice little route tester utility which can save a lot of time. This utility quickly displays in Red and Green color what Route patterns have matched for a particular URL. So we can type in various URLs in the addressbar to see which routes matches.

Lets now looks at a different problem, we normally define all the routes in the global.aspx.cs file, this causes a problem when Routes changes frequently, every single time a new route is added or an existing one is modified we need to recompile web application and upload the new dll to the server, again it is not mandatory to write Routing rules in the global.aspx.cs file, we can easily store the routing rules to a Xml file and use a combination XML related .NET libraries and .NET Reflection APIs to read from the Xml file and create/deserialize Route Objects to add them to the RouteCollection during the Application_Start(). But still we haven't overcome the limitations of restarting the application as the RouteCollection gettting registered during Application_Start. I think we have to live with that, unless we go and implement some kind of FileSystemWatcher to monitor the Xml file and force to refresh the RouteTable.Routes object when the xml file changes. I haven't tried implementing this yet but this would work I think.

We have discussed here, how ASP.NET Routing engine eases writing SEO friendly Url, maitaining Url redirections and tracking centrally. Hope this helps.

Thank you for being with me so far.

ASP.NET tips: Display resultset from Multiple DataTable

shahed — Tue, 10 Feb 2009 17:06:52 GMT

I normally do not use DataSet and prefer Objects instead generated by the ORM frameworks, but recently I had to produce a ASP.NET page that displayed a list of records from multiple DataTables. Lets look at a similar example.

Lets assume we consume this DataSet which has two DataTables "Agent" and "RealEstateProperty". The task is to display, what properties belongs to which agent, in a GridView.

There are different ways to accomplish this task, lets look at them one by one.

Method 1: Bind DataTables to a single GridView

To bind these multiple DataTables to a single GridView control, we can quickly create a new temporary DataTable, with the required fields and populate the Rows and then bind the new DataTable Rows to the GridView.

The above code is self explanatory, where I have created a temporary DataTable, populated its rows by iterating through the original DataTables and then binded the Grid to the new DataTable.Rows. The interesting piece of code to note here is the row.GetChildRows(), which respects the relationship and automatically returns the related child rows. The aspx part looks like the following, where we have a GridView with three columns.

and the RowDataBound code is

Method 2: Bind DataTables to a nested GridView

If we want to avoid creating temporary dummy DataTable as described in method 1, we can use the technique of nested list control. Now we can do this by using

two GridView, or
two DataList, or
two Repeaters or
a combination of Repeater and GridView, or
a combination of Repeater and DataList, or
a combination of GridView and DataList.

We are going to look at a combination of 2 GridViews here, where one GridView is nested inside another, you can do any of the above combinations. For this case the the aspx code is,

Notice the parent and nested GridViews has different onrowdatabound methods. In this technique the parent grid is binded to the the Agent DataTable Rows and the nested GridView is binded to the child RealEstateProperty DataTable Rows. Here is the code.

Method 3: Convert the DataSet to Objects and then bind to GridView

We can generate csharp class from the dataset schema using Xsd.exe and then bind the GridViews to the objects. I have discussed similar technique in one of my previous blog post, where you will find how we can use the Xsd.exe that ships with the .NET Framework.

Example
    C:\temp>xsd propertyDataSet.xsd /l:cs /c
    Microsoft (R) Xml Schemas/DataTypes support utility
    [Microsoft (R) .NET Framework, Version 2.0.50727.42]
    Copyright (C) Microsoft Corporation. All rights reserved.
    Writing file 'C:\temp\propertydatasetclass.cs'.

I also demonstrated a handy DataTableToT() method to assist in converting DataTable to strongly typed object. And when we have the DataTable converted to a stronglytyped object/list/collection it is very easy to bind to the bind to the GridView.

Other Tips
1. DataSet also comes with handy Merge Method, check here, we could have also used this method.
2. When we load a DataSet from xml schema if we do not provide the strongly typed DataSet it will not preserve the Relationship automatically.

Note: The Relations Count = 0;

3. To preserve Relations automatically during a DataSet load from xml, provide strongly typed DataSet. Both of the following methods will automatically preserve the parent child relationship. Also even if you consume them from a webservice client application they will preserve the Relations.

4. DataSet.WriteXml() method serializes the DataSet content and writes XML data.
5. DataSet.WriteXmlSchema() method writes the DataSet structure as XML Schema (xsd file).

Conclusion
We have discussed different techniques to bind multiple DataTables to GridView, we have also discussed some handy tips about the DataSet. Hope this helps.