Determine which file type has been uploaded

It is quite an easy process to upload files from a web browser, but how do you know it is the correct type of document you are asking for?

You can check the file extenstion, but a hacker would just change the file type to another extension, so this is not a fail safe way of checking the file type being uploaded.

Another way which can check for the content of the file being uploaded and look for a signature.

First we will need to hold the signature in a file type, so lets create an enum for them

public enum FileType
    {
        Gif = 7173,
        Jpg = 255216,
        Png = 13780,
        Bmp = 6677,
        TxtAspxAspSql = 239187,
        XlsDocPpt = 208207,
        Xml = 6063,
        Html = 6033,
        Js = 4742,
        XlsxZipPptxMmapZip = 8075,
        Rar = 8297,
        AccdbMdb = 01,
        ExeDll = 7790,
        Bat = 64101,
        Unknown
    }

You’ll notice that some file types have the same signature so you need to be a little careful with these files.

Now for the method that will return our file type:

protected FileType IsImageFile(HttpPostedFileBase file)
        {

            var fs = new FileStream(file.FileName, FileMode.Open, System.IO.FileAccess.Read);
            var br = new BinaryReader(fs);
            string fileclass;
            byte buffer;

            try
            {
                buffer = br.ReadByte();
                fileclass = buffer.ToString();
                buffer = br.ReadByte();
                fileclass += buffer.ToString();
            }
            catch
            {
                return FileType.Unknown;
            }
            finally
            {
                br.Close();
                fs.Close();
            }

            foreach (var type in Enum.GetValues(typeof(FileType)))
            {
                var l = (int)type;
                String[] fileType = {l.ToString()};

                if (fileType.Any(t => fileclass == t))
                {
                    return (FileType)Enum.Parse(typeof(FileType), type.ToString());
                }
            }

            return FileType.Unknown;

        }

That is it, all done

Stay Alive in MVC

Have you ever opened a page for one of your websites and it lags for a while before it finally shows a page but then all of your following requests are quick? If you were to Google the problem you’d find that often it ends up having to do with IIS meeting an idle time limit and shuts down your site.

Keep me Alive

private static void _SetupRefreshJob() {

    //remove a previous job
    Action remove = HttpContext.Current.Cache["Refresh"] as Action;
    if (remove is Action) {
        HttpContext.Current.Cache.Remove("Refresh");
        remove.EndInvoke(null);
    }

    //get the worker
    Action work = () => {
        while (true) {
            Thread.Sleep(60000);
            //TODO: Refresh Code (Explained in a moment)
        }
    };
    work.BeginInvoke(null, null);

    //add this job to the cache
    HttpContext.Current.Cache.Add(
        "Refresh",
        work,
        null,
        Cache.NoAbsoluteExpiration,
        Cache.NoSlidingExpiration,
        CacheItemPriority.Normal,
        (s, o, r) => { _SetupRefreshJob(); }
        );
}

If we place this code in the Global.asax and call it when Application_Start() is raised, we can basically start a job that keeps our website alive. You could just as easily use a Thread to host the refresh method but for this example we simply used an Action delegate.

Once our application starts the refresh job is also started and is saved to the cache. In this example we’re using 60 seconds, but you can change this to be as often as you like.

So How Can We Keep It Fresh?

So how about an example of some code we can use? Here is a simple example that could keep our website alive. Replace the //TODO: in the example above with something like the following.

WebClient refresh = new WebClient();
try {
    refresh.UploadString("http://www.website.com/", string.Empty);
}
catch (Exception ex) {
    //snip...
}
finally {
    refresh.Dispose();
}

This snippet uses a WebClient to actually make an HTTP call to our website, thus keeping the site alive! We could do any number of things from this code like updating local data or get information from external resource. This can be used to keep our site alive and our content refreshed, even if we’re using a Hosted Environment!

It is worth nothing that might not actually need to do an HTTP call back to your website. It is possible that using any method will keep your website from being killed off (but I haven’t tested it yet so let me know what happens if you try it). This example, however, has been tested and works quite well with my provider.

You need to be careful that you don’t call a page with any Analytics attached, otherwise you’ll get false reading in your logs.

Original article

Cross Site Attacks – XSS

Cross Site Attacks (XSS) what is that all about?
 
“Cross-site scripting (XSS) is a type of computer security vulnerability typically found in Web applications. XSS enables attackers to inject client-side script into Web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same origin policy. Cross-site scripting carried out on websites accounted for roughly 84% of all security vulnerabilities documented by Symantec as of 2007. Their effect may range from a petty nuisance to a significant security risk, depending on the sensitivity of the data handled by the vulnerable site and the nature of any security mitigation implemented by the site’s owner.”
 
All user’s inputs can be a back door for attacker to attack your site. User’s inputs that we will categorize as un-trusted inputs are :
  • Incoming URLs including Request.QueryString[] values
  • Form post data (Request.Form[] values including values from hidden fields and disabled fields)
  • Cookies
  • Data in HTTP Headers (such as Request.UserAgent and Request.UrlReferrer).
Your site could be attacked by altering the query string, form values, or cookies data. The solution is not to prevent request manipulation but to check that each request is a legal request for the logged-in visitor.

Cross-Site Scripting and HTML Injection

If an attacker can get our site to return some javascript to our visitors, then the attacker’s script can take control of our visitors’ browsing session and by this the attackers can collect the personal information (passwords, credit card details) of our visitors. There are two main ways an attacker follow to get this:

  1. Persistently:  by entering formed malicious input into some feature and hoping we will store it into our database and then issue it back to other visitors.
  2. Non-persistently or Passively : by finding a way of sending malicious data in a request to our application and having our application echo that data back in it is response. The attacker then finds a way to trick a victim into making such a request.

Razor HTML Encoding

The Razor view engine helps protect us against XSS attacks by encoding any data that we refer to using the @ tag to make it safe to display as HTML. This means when we request an URL with a javascript code as a query string, Razor processes the query string value and replaces the special characters and rendering javascript code as a simple text.

Razor view engine treats the contents of MvcHtmlString objects as if they were encoded, even when that is not the case. We can use Html.Raw helper method to include our HTML into the web page without it being encoded.

Request Validation

The goal of request validation is to stop potentially dangerous data ever reaching the application. If the user tries to submit data that looks like it might be HTML, Then ASP.Net throws an exception. This happens before the request is passed to the MVC Framework, so our application never receives the data the user has sent. But the problem with Request Validation is that it rejects any data even slightly resembling an HTML tag, and this can include valid data.

In ASP.Net MVC Framework, request validation is enabled by default. You can disable it by decorate your controller/action method by ValidateInput attribute and passing false to it. If you decorate the controller with it, that means you enabled/disabled request validation for all action methods within this controller (of course not recommended). If you decorate the action method by that attribute, that means you enabled/disabled request validation for all posted data/model properties. Also you can disable request validation for a specific property by decorate it with AllowHtml attribute.

JavaScript String Encoding and XSS

So what if we want to accept javascript code from the user, i.e post a question on stackoverflow. of course we don’t want to refuse it or disable request validation totally. Fortunately, the Ajax helper class has method called JavaScriptStringEncode, which encodes a string so that it safe to display and escapes characters so that JavaScript will understand it. In such case we have to use Html.Raw method around the result generated by the Ajax helper method. If we don’t do this, then Razor HTML encodes the result, and we are back where we started. Session Hijacking:
ASP.Net identifies users by session ID cookie which called ASP.Net_SessionId by default, and if we use Forms Authentication, then a second cookie is used called /AUTH. If an attacker can obtain these cookies, then they can include them in a request to our server and impersonate one of our users. The browser by default preventing the javascript from a site to access cookies of another site. But if the attacker has been able to inject a script into one of our pages, then the browser believes that the script is part of our application and grands access to the session cookies.

We can protect our site by keeping a record of each client IP address when a session starts, we can deny any requests that originate from a different IP. But you should avoid this technique when you deal with the public internet.

We can mark a cookie with the HttpOnly flag, and the browser will hide its existence from javascript but will continue to send it via all HTTP requests. By default ASP.Net marks ASP.Net_SessionId and /AUTH as HttpOnly. Of course you can apply HttpOnly to your session cookies when you create them.

Cross-Site Request Forgery (CSRF):

To save me repeating myself talk a look at this post Preventing Cross Site Request Forgery

Build your MVC application securely

  1. Don’t write any public method inside a controller class that will not be an action method. By default any public method is an action method, other methods should be wrote in model section. If you have to write a method that will not be an action, make sure it will be private or make it public but you must decorate it with NonAction attribute.
  2. Prevent  Model Binding to change sensitive data by using Bind attribute to set up white/black list that restrict which properties model binding is allowed/not allowed to populate.

Preventing Cross Site Request Forgery

What is Cross Site Request Forgery (CSRF)?

“A CSRF attack forces a logged-on victim’s browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim’s browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks.”

Cross-site scripting (XSS) is widely regarded as one of the most used security issue on the web. Few developers pay much attention to another form of attack that’s equally destructive and potentially far easier to exploit. Your application can be vulnerable to cross-site request forgery (CSRF) attacks not because you the developer did something wrong (as in, failing to encode outputs leads to XSS), but simply because of how the whole Web is designed to work.

How CSRF works

All web application platforms are potentially vulnerable to CSRF, but in this post we’ll focus on ASP.NET MVC. Imagine you have a controller class as follows:

public class UserProfileController : Controller
{
    public ViewResult Edit() { return View(); }
 
    public ViewResult SubmitUpdate()
    {
        // Get the user's existing profile data (implementation omitted)
        ProfileData profile = GetLoggedInUserProfile();
 
        // Update the user object
        profile.EmailAddress = Request.Form["email"];
        profile.FavoriteHobby = Request.Form["hobby"];
        SaveUserProfile(profile);
 
        ViewData["message"] = "Your profile was updated.";
        return View();
    }
}

This is all very normal. First, the visitor goes to Edit(), which renders some form to let them change their user profile details. Secondly, they post that form to SubmitUpdate(), which saves the changes to their profile record in the database. There’s no XSS vulnerability here. Everything’s fine, right? We implement this sort of thing all the time…

Unfortunately, this innocent controller is an easy target for CSRF. Imagine that an attacker sets up the following HTML page and hosts it on some server of their own:

<body onload="document.getElementById('fm1').submit()">
    <form id="fm1" action="http://yoursite/UserProfile/SubmitUpdate" method="post">
        <input name="email" value="hacker@somewhere.evil" />
        <input name="hobby" value="Defacing websites" />
    </form>
</body>

Next, they somehow persuade a victim to visit this page. When this HTML page loads, it submits a valid form post to /UserProfile/SubmitUpdate on your server.

Assuming you’re using Windows authentication or some kind of cookie-based authentication system such as Forms Authentication, the automated form post will be processed within the victim’s established authentication context, and will successfully update the victim’s email address to something under the attacker’s control. All the attacker has to do now is use your “forgotten password” facility, and they’re taken control of the victim’s account.

Of course, instead of changing an victim’s email address, they can perform any action that the victim can perform with a single POST request. For example, they might be able to grant administrative permissions to another account, or post something defamatory to a CMS.

Ways to stop CSRF

There are two main ways to block CSRF:

  • Check that incoming requests have a Referer header referencing your domain. This will stop requests unwittingly submitted from a third-party domain. However, some people disable their browser’s Referer header for privacy reasons, and attackers can sometimes spoof that header if the victim has certain versions of Adobe Flash installed. This is a weak solution.
  • Put a user-specific token as a hidden field in legitimate forms, and check that the right value was submitted. If, for example, this token is the user’s password, then a third-party can’t forge a valid form post, because they don’t know each user’s password. However, don’t expose the user’s password this way: Instead, it’s better to use some random value (such as a GUID) which you’ve stored in the visitor’s Session collection or into a Cookie.

Using the AntiForgeryToken helpers

The core ASP.NET MVC package includes a set of helpers that give you a means to detect and block CSRF using the “user-specific tokens” technique.

To use these helpers to protect a particular form, put an Html.AntiForgeryToken() into the form, e.g.,

@using(Html.Form("UserProfile", "SubmitUpdate")) 
{
    @Html.AntiForgeryToken()
    <!-- rest of form goes here -->
}

This will output something like the following:

<form action="/UserProfile/SubmitUpdate" method="post">
    <input name="__RequestVerificationToken" type="hidden" value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZpArs" />
    <!-- rest of form goes here -->
</form>

At the same time, Html.AntiForgeryToken() will give the visitor a cookie called __RequestVerificationToken, with the same value as the random hidden value shown above.

Next, to validate an incoming form post, add the [ValidateAntiForgeryToken] filter to your target action method. For example,

[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
    // ... etc
}

This is an authorization filter that checks that:

  • The incoming request has a cookie called __RequestVerificationToken
  • The incoming request has a Request.Form entry called __RequestVerificationToken
  • These cookie and Request.Form values match

Assuming all is well, the request goes through as normal. But if not, boom!, there’s an authorization failure with message “A required anti-forgery token was not supplied or was invalid”.

This prevents CSRF because even if a potential victim has an __RequestVerificationToken cookie, an attacker can’t find out its value, so they can’t forge a valid form post with the same value in Request.Form. But legitimate users aren’t inconvenienced at all; the mechanism is totally silent

Anti-CSRF and AJAX

The simple solution for adding AJAX Cross-Site request forgery is to add the Request Verification Token to the data

function CallAjax() {
    var data = { "ajaxparameter ": 'hello moon' };
    data.__RequestVerificationToken = $("input[name=__RequestVerificationToken]").val();
    $.ajax({
        type: "POST",
        url: '@Url.Action("AjaxCall")',
        dataType: "json",
        data: JSON.stringify(data),
        success: function () {
            alert('Ajax call succesful');
        }
    });
    return false;
}

this can also be done via the $ajaxSetup

$.ajaxSetup({
    global: true,
    beforeSend: function (xhr, settings) {
        if (settings.data != "") {
            settings.data += '&';
        }
        settings.data += '__RequestVerificationToken=' + $("input[name=__RequestVerificationToken]").val();
    }
});

this then leaves the AJAX call as you would normally find it

function CallAjax() {
    var data = { "ajaxparameter ": 'hello moon' };
    $.ajax({
        type: "POST",
        url: '@Url.Action("AjaxCall")',
        dataType: "json",
        data: JSON.stringify(data),
        success: function () {
            alert('Ajax call succesful');
        }
    });
    return false;
}

The form token can be a problem for AJAX requests, because an AJAX request might send JSON data, not HTML form data. One solution is to send the tokens in a custom HTTP header. The following code uses Razor syntax to generate the tokens, and then adds the tokens to an AJAX request.  The tokens are generated at the server by calling AntiForgery.GetTokens.

<script>
    @functions{
        public string TokenHeaderValue()
        {
            string cookieToken, formToken;
            AntiForgery.GetTokens(null, out cookieToken, out formToken);
            return cookieToken + ":" + formToken;                
        }
    }

    $.ajax("api/values", {
        type: "post",
        contentType: "application/json",
        data: {  }, // JSON data goes here
        dataType: "json",
        headers: {
            'RequestVerificationToken': '@TokenHeaderValue()'
        }
    });
</script>

When you process the request, extract the tokens from the request header. Then call the AntiForgery.Validate method to validate the tokens. The Validate method throws an exception if the tokens are not valid.

void ValidateRequestHeader(HttpRequestMessage request)
{
    string cookieToken = "";
    string formToken = "";

    IEnumerable<string> tokenHeaders;
    if (request.Headers.TryGetValues("RequestVerificationToken", out tokenHeaders))
    {
        string[] tokens = tokenHeaders.First().Split(':');
        if (tokens.Length == 2)
        {
            cookieToken = tokens[0].Trim();
            formToken = tokens[1].Trim();
        }
    }
    AntiForgery.Validate(cookieToken, formToken);
}

Using salt

Salt? What? In case you want to protect multiple forms in your application independently of each other, you can use a “salt” value when you call Html.AntiForgeryToken(), e.g.,

@Html.AntiForgeryToken("someArbitraryString")

… and also in [ValidateAntiForgeryToken], e.g.,

[ValidateAntiForgeryToken(Salt="someArbitraryString")]
public ViewResult SubmitUpdate()
{
    // ... etc
}

Salt is just an arbitrary string. A different salt value means a different anti-forgery token will be generated. This means that even if an attacker manages to get hold of a valid token somehow, they can’t reuse it in other parts of the application where a different salt value is required

Load balancing

Will different web servers in a load balanced configuration create the same token in the HTML forms?

If all machines across the farm share the same <machineKey>, everything will work. There are lots of resources on how to set this. There’s also a tutorial on MSDN.

Note that the name <machineKey> is a bit misleading, since this is actually set per-application in ~/Web.config. So set the <machineKey> explicitly in your app’s Web.config, then deploy across your farm.

Limitations of the Anti-Forgery helpers

ASP.NET MVC’s anti-CSRF helpers work very nicely, but you should be aware of a few limitations:

  • All legitimate visitors must accept cookies (otherwise, [ValidateAntiForgeryToken] will deny their form posts). Arguably this isn’t a limitation, because unless visitors allow cookies, you probably don’t have anything to protect anyway.
  • It only works with POST requests, not GET requests. Arguably this isn’t a limitation, because under the normal HTTP conventions, you shouldn’t be using GET requests for anything other than read-only operations.
  • It’s easily bypassed if you have any XSS holes on your domain. An XSS hole would allow an attacker to read a victim’s anti-forgery token value, then use it to forge valid posts. So, don’t have XSS holes!
  • It relies on the potential victim’s browser implementing cross-domain boundaries solidly. Browsers are supposed to stop foreign domains from reading your app’s response text and cookies, and are supposed to stop foreign domains from writing cookies to your domain. If an attacker manages to find a way around this, they can bypass [ValidateAntiForgeryToken]. Of course that’s not supposed to be possible. For the most part, modern browsers block this line of attack.

Links

The Open Web Application Security Project

The orginal article was produced by Steven Sanderson:
Prevent Cross-Site Request Forgery (CSRF) using ASP.NET MVC’s AntiForgeryToken() helper

Source for this article

CrossSiteRequestForgery.zip (3.21 mb)

How to test “Only certain roles should have access to a controller” in MVC

Using the TDD approach in an MVC application, I was wondering how can you ensure that only certain roles have access to the controller.  Why should we test for this?  Because this is a clearly defined business rule and all business rules need to have Unit Tests where possible.

This is the code, which is quite simple

[Authorize(Roles = "Administrators")]
public class AdminController : Controller

What we need to ensure is that a developer does not come along and add more roles or take away the Administrators roles.

We can do this using a Test and going through the Controller using reflection, like this:

[TestMethod]
public void AdminControllerShouldOnlyAvailableToAdministrators()
        {
            // Arrange
            var attributes = typeof(AdminController).GetCustomAttributes(true).ToList();
            var countNonAdministrator = 0;
            var countAdministrator = 0;

            // Act
            foreach (var attribute in
                attributes.Where(attribute => attribute.GetType() == typeof(AuthorizeAttribute)).Cast<AuthorizeAttribute>())
            {
                countNonAdministrator = attribute.Roles.Split(',').ToList().Count(role => role.ToString() != "Administrator");
            }

            foreach (var attribute in
                attributes.Where(attribute => attribute.GetType() == typeof(AuthorizeAttribute)).Cast<AuthorizeAttribute>())
            {
                countAdministrator = attribute.Roles.Split(',').ToList().Count(role => role.ToString() == "Administrator");
            }

            // Assert
            Assert.IsTrue(countNonAdministrator  == 0, "Administrators are only allowed to be authorised to use this controller");
            Assert.IsTrue(countAdministrator == 1, "You must only have Administrators to be authorised to use this controller");
        }

 

Encrypting Web.config for the website

Security is always high for installation to customer so is it not about time you encripted the connection string in your web.config file?

This is how it looks like before encrypting:

<connectionStrings>
  <add name="Pubs" connectionString="Server=localhost;Integrated Security=True;Database=Pubs"
    providerName="System.Data.SqlClient" />
  <add name="Northwind" connectionString="Server=localhost;Integrated Security=True;Database=Northwind"
    providerName="System.Data.SqlClient" />
</connectionStrings>

We can encrypt any section of your Web.config file on-the-fly and programatically. If you have full access to your Web server, you can encrypt your connection strings with this single command-line located in the in the %windows%\Microsoft.NET\Framework\versionNumber folder:

aspnet_regiis -pe "connectionStrings" -app "/SampleApplication"

Now, the section in your Web.config file will look like this:

<connectionStrings>
  <EncryptedData>
    <CipherData>
      <CipherValue>AQAAANCMndjHoAw...</CipherValue>
    </CipherData>
  </EncryptedData>
</connectionStrings>

If you can’t execute commands in your web server, for example, when using shared hosting, you still can encrypt it programatically:

Configuration config = Configuration.GetWebConfiguration(Request.ApplicationPath);
ConfigurationSection section = config.Sections["connectionStrings"]; 
section.ProtectSection ("DataProtectionConfigurationProvider"); 
config.Update();

References: Encrypting Web.Config Values in ASP.NET 2.0

Upgrading an ASP.NET MVC 3 Project to ASP.NET MVC 4

 

ASP.NET MVC 4 can be installed side by side with ASP.NET MVC 3 on the same computer, which gives you flexibility in choosing when to upgrade an ASP.NET MVC 3 application to ASP.NET MVC 4.

The simplest way to upgrade is to create a new ASP.NET MVC 4 project and copy all the views, controllers, code, and content files from the existing MVC 3 project to the new project and then to update the assembly references in the new project to match any non-MVC template included assembiles you are using. If you have made changes to the Web.config file in the MVC 3 project, you must also merge those changes into the Web.config file in the MVC 4 project.

To manually upgrade an existing ASP.NET MVC 3 application to version 4, do the following:

In all Web.config files in the project (there is one in the root of the project, one in the Views folder, and one in the Views folder for each area in your project), replace every instance of the following text (note: System.Web.WebPages, Version=1.0.0.0 is not found in projects created with Visual Studio 2012):

System.Web.Mvc, Version=3.0.0.0
System.Web.WebPages, Version=1.0.0.0
System.Web.Helpers, Version=1.0.0.0
System.Web.WebPages.Razor, Version=1.0.0.0

with the following corresponding text:

System.Web.Mvc, Version=4.0.0.0
System.Web.WebPages, Version=2.0.0.0
System.Web.Helpers, Version=2.0.0.0
System.Web.WebPages.Razor, Version=2.0.0.0

In the root Web.config file, update the webPages:Version element to “2.0.0.0” and add a new PreserveLoginUrl key that has the value “true”:

<appSettings>
  <add key="webpages:Version" value="2.0.0.0" />
  <add key="PreserveLoginUrl" value="true" />
</appSettings>

n Solution Explorer, right-click on the References and select Manage NuGet Packages. In the left pane, select Online\NuGet official package source, then update the following:

  • ASP.NET MVC 4
  • (Optional) jQuery, jQuery Validation and jQuery UI
  • (Optional) Entity Framework
  • (Optonal) Modernizr

In Solution Explorer, right-click the project name and then select Unload Project. Then right-click the name again and select Edit ProjectName.csproj.

Locate the ProjectTypeGuids element and replace {E53F8FEA-EAE0-44A6-8774-FFD645390401} with {E3E379DF-F4C6-4180-9B81-6769533ABE47}.

Save the changes, close the project (.csproj) file you were editing, right-click the project, and then select Reload Project.

If the project references any third-party libraries that are compiled using previous versions of ASP.NET MVC, open the root Web.config file and add the following three bindingRedirect elements under the configuration section:

<configuration>
  <!--... elements deleted for clarity ...-->
 
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Helpers" 
             publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0"/>
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Mvc" 
             publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="4.0.0.0"/>
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.WebPages" 
             publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0"/>
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

Original article can be found at: MVC 4 release notes

 

Using MEF in MVC to inject Controllers

After travelling for a year I was interest to see if MEF would work with MVC, and after some digging around I found it can.

***UPDATED****

Added a CastleWindsor example

With any MEF you’ll need a Composition Factory which in this case I’ll place in the MEF directory, but it can be in a different project if required.

public class CompositionContainerFactory
    {
        public CompositionContainer CreateContainer()
        {
            var path = HostingEnvironment.MapPath("~/bin");

            if (path == null) throw new Exception("Unable to find the path");

            var catalog = new DirectoryCatalog(path);

            return new CompositionContainer(catalog);
        }
    }

Now comes the interesting part, in MVC 3 Microsoft introduced the IDependencyResolver, which gets the services when needed.

So implementing the IDependencyResolver with MEF was a little trickier

public class MEFDependencyResolver : IDependencyResolver
    {
        private readonly CompositionContainer _container;

        public MEFDependencyResolver(CompositionContainer container)
        {
            if (container == null) throw new ArgumentNullException("container");

            _container = container;
        }

        public object GetService(Type serviceType)
        {
            if (serviceType == null) throw new ArgumentNullException("serviceType");

            var name = AttributedModelServices.GetContractName(serviceType);

            return Enumerable.Any(_container.Catalog.Parts.SelectMany(part => part.ExportDefinitions), e => e.ContractName == name) ? _container.GetExportedValue<object>(name) : null;
        }

        public IEnumerable<object> GetServices(Type serviceType)
        {
            if (serviceType == null) throw new ArgumentNullException("serviceType");

            var name = AttributedModelServices.GetContractName(serviceType);

            return _container.GetExportedValues<object>(name);
        }
    }

The final step we will need to set the Dependency Resolver and this is done in the Application Start inside the Global.asax

protected void Application_Start()
        {
            AreaRegistration.RegisterAllAreas();

            RegisterGlobalFilters(GlobalFilters.Filters);
            RegisterRoutes(RouteTable.Routes);

            DependencyResolver.SetResolver(new MEFDependencyResolver(new CompositionContainerFactory().CreateContainer()));
        }

Now we are ready to use MEF inside of MVC.

To use MEF inside of MVC just attach the [Export] attribute to controller and then import the object you require, like this:

[Export]
[PartCreationPolicy(CreationPolicy.NonShared)]
public class HomeController : Controller
    {
        [ImportMany]
        private List<IAddress> Addresses { get; set; }

        public ActionResult Index()
        {
            return View(Addresses);
        }
    }

Make sure that the Part Creation Policy is Non-Shared otherwise you will only be able to visit the page once.

That is it, what more could you want, oh the code samples, which I have update to MVC 5.2

DI_Controller_Sample

CastleWindsorControllerInjection

 

 

Upgrading from MVC 2.0 to MVC 3.0

Have you tried to upgrade an MVC 2.0 application to MVC 3.0, it’s not easy as you need to change a lot of configuration.

Well Eilon Lipton has a codeplex project to make life easier ASP.NET MVC 3 Application Upgrader. This is a standalone application that takes the troubles away for you and delivers an MVC 3.0 application

Mvc3AppConverter.zip (430.58 kb)

ASP.NET MVC Routing checker

I came across this nice little MVC routing checker by Phil Haacket

http://haacked.com/archive/2008/03/13/url-routing-debugger/

Simple to use just add

RouteDebug.RouteDebugger.RewriteRoutesForTesting(RouteTable.Routes);

in to the Application_Start of your Global.asax and it does all the reporting on all your Routings

RouteDebug-Binary.zip (4.80 kb)

RouteTesterDemo.zip (16.81 kb)