Thursday, 19 December 2013

How to Restrict Access by IP in ASP.NET MVC and Azure

There are several ways to do this including using HTTP Modules here and here or creating an Action Filter in ASP.NET MVC like this.

They are all working and useful to be used based on your requirement. But there are some pros and cons with them in different situations. Consider that you need to filter the access to some sub-folders of your web application without making them as an IIS application, then the HTTP module method may not work for you any more or you may don’t want to hard code every single folder in your Action Filter.

The best practice to do it, if you are using IIS 7+, is to use ipSecurity configuration settings and you can use IP ranges and subnet masks out of the box with just simple steps to deny or allow the access. Some examples:

Allow all, but block specific IPs or networks
<security>

   <!-- this line allows everybody, except those listed below -->
   <ipSecurity allowUnlisted="true"> 

       <!-- removes all upstream restrictions -->
       <clear/>

       <!-- blocks the specific IP of 83.116.19.53  -->
       <add ipAddress="83.116.19.53"/>

       <!--blocks network 83.116.119.0 to 83.116.119.255-->
       <add ipAddress="83.116.119.0" subnetMask="255.255.255.0"/>

       <!--blocks network 83.116.0.0 to 83.116.255.255-->
       <add ipAddress="83.116.0.0" subnetMask="255.255.0.0"/>

       <!--blocks entire /8 network of 83.0.0.0 to 83.255.255.255-->
       <add ipAddress="83.0.0.0" subnetMask="255.0.0.0"/>

   </ipSecurity>
</security>

Deny all, but allow specific IPs or networks
<security>

    <!-- this line blocks everybody, except those listed below --> 
    <ipSecurity allowUnlisted="false"> 

       <!-- removes all upstream restrictions -->
       <clear/> 

       <!-- allow requests from the local machine -->
       <add ipAddress="127.0.0.1" allowed="true"/>

       <!--allow network 83.116.119.0 to 83.116.119.255-->
       <add ipAddress="83.116.119.0" subnetMask="255.255.255.0" allowed="true"/> 

       <!-- allow the specific IP of 83.116.19.53  --> 
       <add ipAddress="83.116.19.53" allowed="true"/>  

       <!--allow network 83.116.0.0 to 83.116.255.255-->
       <add ipAddress="83.116.0.0" subnetMask="255.255.0.0" allowed="true"/> 

       <!--allow entire /8 network of 83.0.0.0 to 83.255.255.255-->
       <add ipAddress="83.0.0.0" subnetMask="255.0.0.0" allowed="true"/> 

    </ipSecurity>

</security>


To do this on your local or on-premise IIS:

  1. You need to add this feature to your IIS here 
  2. Unlock the feature by running this command in your command prompt %windir%\system32\inetsrv\AppCmd.exe unlock config -section:system.webServer/security/ipSecurity
  3. Add proper configuration to your root web.config by using location tag or add new web.config for each folder you want to limit the access to it.

<location path="YOUR-FOLDER-PATH">

    <system.webServer>

      <security>

        <ipSecurity allowUnlisted="false">

          <clear/>

          <add ipAddress="1.*.*.*"/>

        </ipSecurity>

      </security>

    </system.webServer>

  </location>


The trick for ASP.NET MVC areas is that you need to use the virtual path or route for your folders or routes. For example, if you have an Admin area in your web application the MVC route for it will be /Admin and not Areas/Admin. So you might need to add two location settings to limit the access to your admin area like this:

<location path="Admin">

    <system.webServer>

      <security>

        <ipSecurity allowUnlisted="false">

          <clear/>

          <add ipAddress="127.*.*.*"/>

          <add ipAddress="1.*.*.*"/>

          <add ipAddress="192.*.*.*"/>

        </ipSecurity>

      </security>

    </system.webServer>

  </location>

  <location path="Areas/Admin">

    <system.webServer>

      <security>

        <ipSecurity allowUnlisted="false">

          <clear/>

          <add ipAddress="127.*.*.*"/>

          <add ipAddress="1.*.*.*"/>

          <add ipAddress="192.*.*.*"/>

        </ipSecurity>

      </security>

    </system.webServer>

  </location>

Azure

It turns out that IIS7 doesn’t have the module or role installed for IP Security in Azure (or any Windows 2008 Server) by default. Therefore we must go ahead and install the module ourselves, before the application starts. The way to achieve this is to create a startup task. In this task, first you need to install “IPv4 Address and Domain Restrictions” feature and then Unlocking configuration for “IPv4 Address and Domain Restrictions feature.
To do this, create a new folder at the root level of your web role called startup and, within this folder, create a batch file called startup.cmd. Set the properties of this file to Copy Always to ensure that it will be deployed. In this file we are going to put some shell commands to make the Web Role installs the correct IIS module during its startup. Those commands are:

@echo off

@echo Installing "IPv4 Address and Domain Restrictions" feature

%windir%System32ServerManagerCmd.exe -install Web-IP-Security

@echo Unlocking configuration for "IPv4 Address and Domain Restrictions" feature

%windir%system32inetsrvAppCmd.exe unlock config -section:system.webServer/security/ipSecurity


Then go into the ServiceDefinition.csdef of your Web Role and add the startup task under WebRole tag like so:

<Startup>

<Task commandLine="startup\startup.cmd" executionContext="elevated" taskType="background" />

</Startup>


Note that this startup task type is background. This task would be independent from the Role itself. First, startup task will execute and immediately after the Role, and even when this task is not completed, the Role will start separately from the startup task. So if something goes wrong in the task, your web role won’t fail.
Now you can have the same web configuration as above to restrict the access to some folders.

Thursday, 12 September 2013

Why AOP Is Good For Your Health!

What Is AOP?

One important part of every well designed software application is its “Crosscutting concerns” something that we may call non-functional requirement. These functionalities are needed across many different layers, modules, classes within the application. Some examples are:

  • Logging
  • Instrumentation
  • Security
  • Error Handling
  • Caching
  • Validation

These concerns often cannot be cleanly decomposed from the rest of the system or core concerns in both the design and implementation, and can result in either code duplication, coupling between systems, or both.

Aspect-Oriented Programming (AOP) helps to separate crosscutting concerns from the core concerns, by putting them into a separate module so we can plug that module into the core whenever needed without cluttering the code.

Why It Is Good For Your/Application Health?

So why AOP is good for your health?! The short answer is: It helps you write less code and makes your life easier! So you can have more free time to spend on whatever you want e.g. going to the gym or something useful for your health or life!

Here is the longer and more technical answer:

  • The business logic source code is much easier to read and understand.
  • Reusable code means shorter development times and easier troubleshooting.
  • Developers can better focus on implementing the main business logic or core concerns.
  • Less-experienced developers won't have to learn to tackle these crosscutting concerns throughout their code.
  • The crosscutting code can be replaced or upgraded easier.
  • Many AOP tools and frameworks can be configured simply via configuration files without recompiling and redeploying the application which means easier maintenance. 
  • Separation of concerns means better unit testing and higher quality software.

As a developer, if you still believe that writing code having above qualities and possibilities makes your life easier (and healthier!), then continue reading to find out how to do AOP in .NET.

How to do AOP?

A common approach to implementing behaviours to address crosscutting concerns in your application is to use the decorator/proxy patterns. But, AOP is not just a decorator! If you have a small application with a few classes, then decorator/proxy combined with dependency injection does the job for you. But, for a bigger and more complicated application, it is recommended to use an AOP framework. For more information see this: aop vs decorator.
There are several AOP implementations in .NET Framework with different capabilities and pros and cons and reviewing all of them is beyond the scope of this post. So, I will introduce only two of them which I have used.

Postsharp

Postsharp is by SharpCrafters and it claims to be the most comprehensive aspect-oriented software available for .NET. It is not free or open source and its free version is limited.
PostSharp uses .NET attributes and does its work at build time after the compiler has generated the IL from your code to produce the final result using MSIL rewriting techniques.

The good thing about Postsharp is it is only a compile time thing and there won’t be performance penalty at runtime. The bad thing is, it is tied to your current compiler version and build configuration (i.e. 32 or 64 bits) and sometimes it slows down you to use for example the newer version of Visual Studio and you need to wait for a newer version of Postsharp or pay for an upgrade. And of course, there is a significant hit with compilation time in bigger applications.

Unity Interception

As said before, a common approach to implementing behaviours to address crosscutting concerns in your application is to use the decorator pattern. Instead of wiring the decorators up manually, you could use the Unity container to do it for you.
Unity is one of the Enterprise Library application blocks. Unity is essentially a DI container with additional support for an interception mechanism through which you can make your classes a bit more aspect-oriented.
Unity uses the Interception design pattern to dynamically create a proxy object that it inserts between the client and the target object.

The good thing about Unity Interception is that it could be configured through configuration files using matching rules, call handlers and interceptors and in comparison to Postsharp, you don’t need to add attributes to your methods or classes and of course it is from Microsoft and it is free as part of the Enterprise Library. The bad thing could be its runtime nature that can have a small performance cost.

Monday, 20 May 2013

Command and Query Responsibility Segregation (CQRS)

Recently, I needed to design a new application with a non-functional requirement to have a good performance in searches and viewing the page results. So, it was mostly about the "Read".
I have been using Domain Driven Design or DDD for transactional applications for a while and my feeling was that this is not what I need this time exactly.
The main reason was the complicated domain models with several child objects and collections and so many mappings from database to the domain model and then to DTOs and finally to view models.
Domain models are the heart of any DDD applications, and I needed DTOs for my distributed fa├žade and them view models for the MVC part.
The answer for my new application was CQRS or Command Query Responsibility Segregation pattern:
"At its heart it is a simple notion that you can use a different model to update information than the model you use to read information."
Martin Fowler
Please note that it is not against DDD while you still need or can use DDD with it. When we say "CQRS" this often means: "CQRS Principle" + "Message-driven architecture with commands, events and queries" + "Domain-Driven Design Methodology".

I am not going to define it here or show you different diagrams or different aspects of it in this post. Instead, the main purpose of this post is to share some good sources that I have used to learn it and implement it into a way that worked for my application.

CQRS by Martin Fowler

CQRS Starting Page : This is a very complete reference page for CQRS by Rinat Abdullin which you can find sample implementations too.

Top 10 Reasons to do CQRS

CQRS Journey: This is from Microsoft patterns & practices

Clarified CQRS

Introduction to CQRS: a good article and easy to understand

DDD/CQRS:  A discussion group on Google

I am sure that you can find better sources, but these are what I liked :)

Happy CQRS!

Monday, 21 January 2013

ASP.NET MVC Model Binding for Base Classes

In ASP.NET MVC, sometimes there is a need to have several model classes inheriting from a base model class. When all child classes share a common property from the base class, then it is useful to use model binders to bind a value to the shared properties.

Using ASP.NET MVC 4.0, in below snippets, the ProfileModelBase is the base class for AboutModel and BasicInfoModel classes.
    public class ProfileModelBase
    {
        public string UserName { get; set; }
    }

    public class AboutModel : ProfileModelBase
    {
        public string About { get; set; }
    }

    public class BasicInfoModel : ProfileModelBase
    {
        public DateTime Birthday { get; set; }

        public string FirstName { get; set; }

        public string LastName { get; set; }
    }

One solution to do the "Don't Repeat Yourself (DRY)" for above code is to use a model binder to assign a value to the UserName property using below code:

    public class ProfileModelBinder : DefaultModelBinder
    {
        protected override void OnModelUpdated(ControllerContext controllerContext, ModelBindingContext bindingContext)
        {
            var userProfileBase = bindingContext.Model as ProfileModelBase;
            if (userProfileBase != null)
            {
                userProfileBase.UserName = controllerContext.HttpContext.User.Identity.Name;
            }

            base.OnModelUpdated(controllerContext, bindingContext);
        }
    }

In above code, I am using OnModelUpdate event to set the value of the UserName property. Using this model binder, our model classes will be:

    [ModelBinder(typeof(ProfileModelBinder))]
    public class AboutModel : ProfileModelBase
    {
        public string About { get; set; }
    }

    [ModelBinder(typeof(ProfileModelBinder))]
    public class BasicInfoModel : ProfileModelBase
    {
        public DateTime Birthday { get; set; }

        public string FirstName { get; set; }

        public string LastName { get; set; }
    }

That's it! No more repeating code.

Enjoy model binding!