Tags: , , | Categories: Articles, Labs Posted by RTomlinson on 8/19/2010 8:49 PM | Comments (0)

.NET 4.0 sees the introduction of Code Contracts. Code Contracts allow the developer to specify rules and "assumptions on your code in the form of pre-conditions, post-conditions and object invariants" (in the words of DevLabs). What this means in real terms is that we are able to apply contractual rules to methods or properties where typically we would have applied other input sanitizing methods.

Take, for example, an SMS messaging application where we have a dispatching service class. This class is responsible for sending out messages and contains a single Send method. A pre-condition to this method may be that the message length can only be 140 characters (as is typically the case). Code Contracts allows us to design our object and specify this contract as a condition to the method.

There are three ways to utilise this feature.

  1. Runtime Code Checking - Your code will be modified with the contracts at runtime and allows for runtime results.
  2. Static Code Analysis - A static checker that can check broken conditions and violations.
  3. Document Generation - Although I haven't used this facility, it is able to generate XML documentation.

I start by creating an interface for my message dispatcher that contains my single Send method.

   1:  using System.Diagnostics.Contracts;
   2:   
   3:  namespace CodeContractsFirstLook.Contracts
   4:  {
   5:      [ContractClass(typeof(MessageDispatcherServiceContract))]
   6:      public interface IMessageDispatcherService
   7:      {
   8:          bool Send(IMessage message);
   9:      }
  10:  }

As you can see this dispatcher service interface is attributed with the ConcreteClass attribute that is part of the System.Diagnostics.Contracts namespace. This tells the checker which contract class applies to the concrete class that implements this interface. Let's see what the contract class (MessageDispatcherServiceContract) looks like:

   1:  using System.Diagnostics.Contracts;
   2:   
   3:  namespace CodeContractsFirstLook.Contracts
   4:  {
   5:      [ContractClassFor(typeof(IMessageDispatcherService))]
   6:      public sealed class MessageDispatcherServiceContract : IMessageDispatcherService
   7:      {
   8:          bool IMessageDispatcherService.Send(IMessage message)
   9:          {
  10:              Contract.Requires(message.messageBody.Length < 140);
  11:              return default(bool);
  12:          }
  13:      }
  14:  }

Here the contract is specified on line 10. What we are saying here is that whenever a class implements the IMessageDispatcherService interface and the Send method is called we are going to evaluate the Requires method as a pre-condition to the method. In this case the condition is that the message body is less than 140 characters in length.

By default we must return something where the method siganture has a return type, otherwise our code won't compile. Here, I use the default keyword to return the default for the type bool.

Now let's take a look at the actual MessageDispatcherService that implements the IMessageDispatcherService interface and therefore will execute our interface contract:

   1:  using CodeContractsFirstLook.Contracts;
   2:   
   3:  namespace CodeContractsFirstLook
   4:  {
   5:      public class MessageDispatcherService : IMessageDispatcherService
   6:      {
   7:          public bool Send(IMessage message)
   8:          {
   9:              // It doesn't matter what we do here
  10:              // Our Contracts will be executed
  11:   
  12:              return true;
  13:          }
  14:      }
  15:  }

As our interface has a contract associated with it, whenever the method above is executed our contract code will execute to evaluate the message body length. We can test this code works with a simple console application.

   1:  using System;
   2:  using CodeContractsFirstLook.Messaging;
   3:  using CodeContractsFirstLook;
   4:   
   5:  namespace ConsoleApplication1
   6:  {
   7:      class Program
   8:      {
   9:          static void Main(string[] args)
  10:          {
  11:              var message = new SmsMessage();
  12:              var messageDispatcher = new MessageDispatcherService();
  13:   
  14:              message.messageBody = "This will certainly pass";
  15:              Console.WriteLine(string.Format("Was message dispatching successful? {0} ", 
  16:                  messageDispatcher.Send(message)));
  17:   
  18:              message.messageBody = "A very long message that surely must be over one hundred and forty characters by now...surely! Let me copy and paste into word to do a character count....a yes....we're good!";         
  19:              Console.WriteLine(string.Format("Was message dispatching successful? {0} ", 
  20:                  messageDispatcher.Send(message)));
  21:          }
  22:      }
  23:  }

Conclusion

In this post I've covered a very simplified overview of Code Contracts and a basic introduction as to how you can use the .NET 4.0 System.Diagnostics.Contracts to specify pre-conditions on methods, specifically using interface contracts.

This is very much the tip of the iceberg when it comes to the subject of Code Contracts.

One of the biggest benefits is the ability to ensure loose coupling of contracts from class code through interface contracts and the "Design-By-Contract" pattern seems a much neater implementation than the normal input sanitization/exception throwing mechanism that we typically deal with day-to-day.

What you need to get started

To get started you will need to download the Code Contracts project from DevLabs. This will add a "Code Contracts" panel to your projects properties (right-click on your project in Visual Studio and go to Properties). In order to perform runtime checks you will need to select the "Perform Runtime Contract Checking" option (see below):

Want to know more?

http://www.developer.com/net/article.php/3836626/Understanding-and-Benefiting-from-Code-Contracts-in-NET-40.htm

http://www.cauldwell.net/patrick/blog/CodeContracts.aspx

http://blogs.msdn.com/b/bclteam/archive/2008/11/11/introduction-to-code-contracts-melitta-andersen.aspx

http://msdn.microsoft.com/en-us/devlabs/dd491992.aspx

 

Download my solution code sample:

CodeContractsFirstLook.zip (66.36 kb)

Tags: , , | Categories: Articles, Tutorials Posted by RTomlinson on 6/15/2010 10:15 PM | Comments (0)

The Telerik RadGrid is a great grid component for .NET developers and I can't recommend it, or the rest of the ASP.NET controls from Telerik, highly enough. The control has a vast amount of options, from drag and drop columns, filtering, templating and hierarchical databinding. Go and check out the demo's on their demo website. This post will cover setting up the data access for true data paging as well as hooking into the appropriate server side events

The grid can handle 300,000 rows with in-memory databinding, according to the Telerik website. When you potentially reach this upper limit and beyond you want to look at true data paging of results SQL Server side, which is made even more easier in SQL Server 2005 and later using Common Table Expressions. This is the most efficient way of data paging within SQL by supplying a page number and a page size to work out the record set to retrieve, improving website response time and saving memory allocation. See an example below:

CREATE PROCEDURE [dbo].[Web_Accounts_Get]
    @CompanyID int,
    @PageSize int = 10,
    @PageNumber int = 1
AS
BEGIN
    SET NOCOUNT ON;

    DECLARE @PageRecordStart INT
    DECLARE @PageRecordEnd INT

    SET @PageRecordStart = ((@PageNumber - 1 ) * @PageSize) + 1
    SET @PageRecordEnd = @PageNumber * @PageSize 


    ;WITH Accounts_Page AS
    (
        SELECT Row_Number() OVER (ORDER BY [AccountName]) AS RowNo
            ,[Id]
          ,[CompanyID]
          ,[AccountID]
          ,[AccountName]
          ,[PostCode]
          ,[AccountTypeID]
          ,[DateUpdated]
          ,[DateAdded]
        FROM [dbo].[tblAccount] WITH (NOLOCK)
        WHERE [CompanyID] = @CompanyID
    )
    SELECT ,[Id]
          ,[CompanyID]
          ,[AccountID]
          ,[AccountName]
          ,[PostCode]
          ,[AccountTypeID]
          ,[DateUpdated]
          ,[DateAdded]
    FROM Accounts_Page
    WHERE RowNo BETWEEN @PageRecordStart and @PageRecordEnd 
    ORDER BY RowNo ASC;

END

The Telerik RadGrid exposes an OnNeedDataSource event that you can hook into to provide data access to bind to the grid. Here I use the RadGrid's CurrentPageIndex and PageSize properties to pass to my data access for our SQL CTE.

        protected void rdgrdAccounts_OnNeedDataSource(object sender, GridNeedDataSourceEventArgs e)
        {
            int startRowIndex = rdgrdAccounts.CurrentPageIndex + 1;
            int maximumRows = rdgrdAccounts.PageSize;

            rdgrdAccounts.VirtualItemCount = Account.CountForFilters(CompanyId, filters);
            rdgrdAccounts.DataSource = Account.GetAccounts(CompanyId, maximumRows, startRowIndex);
            
        }

In the next post I will cover allowing multiple checkbox selection of rows when using true data paging.

Tags: , , , | Categories: Articles Posted by RTomlinson on 1/7/2010 7:07 AM | Comments (4)

Today I spent a stupid amount of time trying to resolve an issue that had me banging my head off the desk. To save anyone else from the sheer frustration I thought I would write about it to hopefully save anyone else from wasting their time.

I began writing a custom composite control that contained a dropdownlist. This dropdownlist required data binding to a list of business objects. Simple and common scenario. I would then databind the dropdownlist to the control in the page behind (see code sample below).

   1:  using System;
   2:  using System.Web;
   3:  using System.Web.UI.WebControls;
   4:  using System.ComponentModel;
   5:   
   6:  namespace SSControls
   7:  {
   8:      public class MapControl : CompositeControl
   9:      {
  10:          public MapControl() { }
  11:   
  12:          DropDownList _ddlAccountTypes = new DropDownList();
  13:   
  14:          public DropDownList AccountTypes
  15:          {
  16:             get
  17:             {
  18:                 return _ddlAccountTypes;
  19:             }
  20:          }
  21:   
  22:          protected override void CreateChildControls()
  23:          {
  24:              Controls.Add(_ddlAccountTypes);
  25:          }
  26:      }
  27:  }

   1:  public class AccountMap : System.Web.UI.Page
   2:  {
   3:      protected void Page_Load(object sender, EventArgs e)
   4:      {
   5:        if (!IsPostBack)
   6:        {
   7:            mapControl.AccountTypes.DataSource = Accounts.GetAccounts(123);
   8:            mapControl.AccountTypes.DataBind();
   9:        }
  10:      }
  11:  }

As simple as it sounds whenever a postback was issued the data in the dropdownlist was lost. Now the first thought of any developer is probably that this is either a ViewState issue or a databinding issue.

Let's think about what happens when we perform data binding on a composite control. The benefit of inheriting from CompositeControl is that child controls have their ViewState automatically tracked and we don't have to go through the pain of the whole IPostBackEventHandler complexity and the loading and saving of ViewState.

So why do we lose our data upon postback? The problem is that ViewState is only tracked once it has been added to the Controls collection in the CreateChildControls() method. Therefore if we call DataBind() on a child control before it is added to the Controls collection then the ViewState is not being tracked. The result of this (apart from a massive headache) is that when we issue a postback we lose the ViewState information from out dropdownlist. 

The solution? As painful as it is for me to say, make sure that you data bind after your child control has been added to the controls collection, as follows:

   1:  using System;
   2:  using System.Web;
   3:  using System.Web.UI.WebControls;
   4:  using System.ComponentModel;
   5:   
   6:  namespace SSControls
   7:  {
   8:      public class MapControl : CompositeControl
   9:      {
  10:          public MapControl() { }
  11:   
  12:          DropDownList _ddlAccountTypes = new DropDownList();
  13:   
  14:          public DropDownList AccountTypes
  15:          {
  16:             get
  17:             {
  18:                 return _ddlAccountTypes;
  19:             }
  20:          }
  21:   
  22:          protected override void CreateChildControls()
  23:          {
  24:              Controls.Add(_ddlAccountTypes);
  25:              if (!Page.IsPostBack)
  26:                  _ddlAccountTypes.DataBind();
  27:          }
  28:      }
  29:  }

   1:  public class AccountMap : System.Web.UI.Page
   2:  {
   3:      protected void Page_Load(object sender, EventArgs e)
   4:      {
   5:        if (!IsPostBack)
   6:        {
   7:            mapControl.AccountTypes.DataSource = Accounts.GetAccounts(123);
   8:        }
   9:      }
  10:  }

Now when a postback is issued your dropdownlist will have it's values tracked in ViewState and you will not lose data.

Tags: , | Categories: Articles, Labs Posted by RTomlinson on 9/9/2009 2:01 AM | Comments (0)

Let me start by saying that I absolutely HATE Session in ASP.NET. In fact...no I don't...what I mean is that I HATE improper use of Session and I specifically hate when it's used randomly as a poor design choice, typically by insanely aweful developers, you know who you are!

I have in the past designed, and stole, session manager helper classes. Today I was playing around with the idea of returning a strongly typed object from session using a single static helper method. Hardly a life changing post but hopefully someone, somewhere might find it interesting/useful.

public class SessionManager
{
    public static T GetSessionValue<T>(string key, HttpContext context) where T : class
    {
        return context.Session[key] as T;
    }
}

The c# compiler will complain if you return "as T" without a class or method level type constraint. Hence the need for "where T : class".

And its use?

SessionManager.GetSessionValue<string>("Username", Context);

 

Tags: , , | Categories: Articles, Tutorials Posted by RTomlinson on 9/3/2009 6:58 PM | Comments (10)

In Part 1 and Part 2 I covered how I went about building an authorization framework using Rhino Security. I am now going to cover how to integrate this into your domain model (business objects) and how we can use dynamic discovery for permission registration and database persistence.

In essence what I am saying here is that given the scenario whereby we have a domain object (lets use that of a Company business object, for example) we could state what available permissions that object could have. This post will therefore cover:

  • Defining permissions at an object level
  • The ability to register those permissions in the database

Defining Object Permissions

Having considered various implementations, I finally decided to go with an attribute based approach. The attribute requires the operation that you want access control over and to what level of granularity. For example, given the flexibility of the Rhino Security implementation we can use the operation convention of /BUSINESSOBJECT/OPERATION or /BUSINESSOBJECT/METHOD/OPERATION OR /BUSINESSOBJECT/PROPERTY/OPERATION.

In reality this would result in the following examples:

  • /Company/Add
  • /Company/Delete
  • /User/UserName/Set
As you can see this attribute (ACL) used below, it takes as a parameter, the operation and an enum that states what type of permission it is.

namespace MyApp.Core
{
    [ACL("/User/Add", "Restrict the ability to add new users", ACLType.ObjectLevel)]
    public class User : Entity, IUser
    {
        private IAuthorizationRepository _authRepo;
        protected User(IAuthorizationRepository authRepo) 
        {
            _authRepo = authRepo;
        }

        public User() 
        {
            _authRepo = ResolveType.Of<IAuthorizationRepository>();
        }

        [Length(6, 512)]
        [NotNullNotEmpty]
        public virtual string UserName { get; set; }

        [Length(6, 512)]
        [NotNullNotEmpty]
        public virtual string Password { get; set; }

 

Dynamic Permissions Discovery

Having created an attribute to apply the required information to an object we can use reflection to discover all of our permissions. Those permissions that have not been registered in the database can then be registered and any that no longer exist can be marked accordingly. The way that I implemented this was run this discovery in the Application_Start event of the Global.asax. Therefore whenever we start our application this process takes place and the overhead of some pretty heavy reflection is less of an issue.

This process, although sounding quote complex, is actually very very simple. I call a static Discover method that uses relflection to reflect the assembly, find those objects that the ACLAttribute has been applied to, checks whether that object is registered and if not then registers it.

public static void Discover(Castle.Windsor.IWindsorContainer Container)
{
  Assembly asm = Assembly.Load("MyApp.Core");

  Type[] types = asm.GetTypes();

  Type securityPermission = asm.GetType("MyApp.Core.Security.ACLAttribute", false);
  PropertyInfo operation = securityPermission.GetProperty("Operation");
  RegisterAssemblyTypes(Container, types, securityPermission, operation);
}

private static void RegisterAssemblyTypes(Castle.Windsor.IWindsorContainer Container, Type[] types, Type securityPermission, PropertyInfo operation)
{
  foreach (Type t in types)
  {
    object[] objs = t.GetCustomAttributes(securityPermission, false);

    foreach (object o in objs)
    {
      if (!Registered(operation.GetValue(o, null).ToString(), Container))
      {
        Register(operation.GetValue(o, null).ToString(), Container);
      }
    }
  }
}

This implementation works very well. It involves minimal work work the developer. When a new permission is required it simply means adding an attribute to the appropriate business object. This permission will then be automatically registered and will be visible within the permissions section of the application, allowing the administrator to associate a particular user with that permission to allow or deny the operation.

In the next post I will detail the how I implemented this using some nice jQuery iPhone checkboxes on top of the standard ASP.NET checkbox control.

Tags: , , | Categories: Articles Posted by RTomlinson on 7/30/2009 12:12 AM | Comments (12)

Originally this post was going to be titled "Part 2: Integrating Rhino Security" but upon reflection this wasn't what I was trying to acheive at all. This has been covered enough to get you started and if you need to know how to integrate Rhino Security into your ASP.NET WebForms project then read this post by Billy McCafferty. What I do want to discuss is the concept of Rhino Security, its simplicity, adaptability and extensibility and why it is "the shit".

Brief Overview Of Rhino Security Architecture

Rhino security is an authorization framework that is easily integrated into existing .Net applications to provide a security framework that covers a wide range of authorization scenarios from the simple to the complex. In essence, this boils down to permitting or denying a user, or group of users, from carrying out an operation.

Ayende implements operations using the following notation:

  • /Account/Financial/View
  • /Account/Financial/Edit
  • /Account/Financial/Delete
  • /Case/Assign
  • /Employee

The major benefit of this implementation is that the interpretation of the operations is completely up to the developer. I'll give you an example to show you what I mean. In part 1 I outlined that in our application there is a requirement to implement page level permissions. In order to implement this (I will explain the actual page level permissions implementation in the next post) I prefix all page level operations with '/Page/' and append this with the URL of that given page, such as:

  • /Page/Configuration/RolesPermissions/Default
  • /Page/Admin/Users/AddUser

You can start to see that the operations format gives a huge amount of flexibility and scope for the developer to implement page level, object level and feature level permissions without dictating implementation.

Part 1 also described the requirement that permissions must be based on both users and groups. Rhino Security supports this notion by associating permissions with both users and users groups (see schema below).

Rhino Security Schema

Finally Rhino Security has the concept of permission levels. It isn't completely clear from the documentation as to the intended use of the level, although it is clear that higher level override permissions of a lower level. However, I see this as a massive benefit as Ayende leaves the thinking and implementation up to the developer. For example in my implementation I give inherited user groups a higher level than their parent. So given the scenario where you may have a 'Developer' role (users group) which would have associated permissions. You may have another 'Senior Developer' role that is a child of the 'Developer' role. In my implementation the 'Senior Developer' permissions set should have a greater weighting than it's parent as it is more specific. The 'Developer' would therefore have a level of 1 and the 'Senior Developer' will have a level of 2. Again...just to reiterate this is simply my implementation and by no means a restriction of the framework.

Authorization with Rhino Security

Rather than describe the Repositories and Services to get started with Rhino Security as they are better described here, I will run you through a use case and describe the process.

Say, for example, that we have two users, one is called Bill and he is a Senior Developer and another user called Tom and he is a Junior Developer. Our application must only allow Senior Developers to add new companies to the system.

Given that Rhino Security is integrated into our system, whereby we already have a User table to which Bill and Tom are registered in, the first thing we must do is create our UsersGroups. The way I'm going to do this is to create a parent UsersGroup for Developers, to which Junior and Senior developer roles will inherit from.

_authRepository = ResolveType.Of<IAuthorizationRepository>();

_authRepository.CreateUsersGroup("Developer");
_authRepository.CreateChildUserGroupOf("Developer", "Junior Developer");
_authRepository.CreateChildUserGroupOf("Developer", "Senior Developer");

Now that we have created the UsersGroups we can add both Bill and Tom to the relevant roles:

IUser userA = _userRepository.GetUser("Bill");
IUser userB = _userRepository.GetUser("Tom");


_authRepository.AssociateUserWith(userA, "Senior Developer"); _authRepository.AssociateUserWith(userB, "Junior Developer");

We can now create the operations that we wish to be authorized against. In this use case we are wanting to restrict access at an object level and will therefore use the convention of /ObjectName/Operation. Therefore we will use /Company/Add.

_authRepository.CreateOperation("/Company/Add");

The IPermissionsBuilderService tie's all of this together to associate the UsersGroups with a particular operation and at a specified level. As you can see from the example below this is implemented using a fluent interface.

private void GrantPermission(string operation, bool allowed, UsersGroup usersgroup)
{
    if (allowed)
    {
        _permissionBuilderService
            .Allow(operation)
            .For(_usersGroup)
            .OnEverything()
            .Level(usersgroup.GroupLevel())
            .Save();
    }
    else
    {
        _permissionBuilderService
            .Deny(operation)
            .For(_usersGroup)
            .OnEverything()
            .Level(usersgroup.GroupLevel())
            .Save();
     }
}

GrantPermission("/Company/Add", false, _authRepository.GetUsersGroupByName("Developer"));
GrantPermission("/Company/Add", true, _authRepository.GetUsersGroupByName("Senior Developer"));

If you are wondering what the GroupLevel() method is or does, this is not part of the UsersGroup object out-of-the-box, I wrote this extension method to implement permission levels, so that all permissions are registered above those of their parents. In our use case, the Senior Developer role is a child group of the Developer UsersGroup and as a result the Senior Developer permissions will be at a level above it's parent. This may make more sense if I show you the extension method.

public static int GroupLevel(this UsersGroup usersGroup)
{
    return usersGroup.AllParents.Count + 1;
}

At this point we pretty much have our use case covered. In summary, Bill and Tom are Developers, Bill is a Senior Dev and Tom a Junior. Bill, as a Senior Dev, is permitted to add companies to the application, Tom as a Junior Dev is not permitted as his parent role prevents him from doing so.

Given that the plumbing is now sorted we can enforce authorization using the bool IAuthorizationService.IsAllowed(IUser user, string operation) method.

// Returns true
bool canBillAddCompany = _authRepository.IsAllowed(userA, "/Company/Add");
// Returns false
bool canTomAddCompany = _authRepository.IsAllowed(userB, "/Company/Add");

 

Conclusion

In reality what I have covered here will be hidden behind some kind of UI or service. This will be covered in later posts. In my next post I will be detailing how to implement a dynamic permissions discovery framework on top of Rhino Security to automate the registration of permission.

 

Tags: , , , | Categories: Articles Posted by RTomlinson on 7/30/2009 12:09 AM | Comments (3)

When discussing authorization in enterprise applications, and particularly when using the .NET framework, the most common answer is to look towards ASP.NET role providers. In many instances this is a fair implementation when it fits in with your application requirements. However, in a lot of cases this just isn't good enough when you need a more granular solution, particularly when permissions come into play with associated roles.

Recently we started to plan a complete rewrite for our flagship product. Given the chance to take a step back and think of our platform outside the bounds of legacy limitations, both in database schema and application architecture, was a great exercise. In doing so we realised that central to our application was the concept of roles (what the business calls persona's) and more importantly permissions.

The requirements that we came up with were:

  • Permissions must be associated with both roles AND users.
  • Operations must not be static i.e. no enums that pertain to CRUD operations.
  • The permissions must span:
    • Page Level Access
    • Object and Method Level Access
    • Feature Level Access
  • Must be easy to develop with, whereby a developer would not forget to implement.

Ultimately we require a web based UI whereby internal support staff can configure the roles and permissions on both a group and user basis, giving them granular control of all permissions. The following screenshot shows the ideal solution. In this case using a custom ASP.NET wizard control (a blog post to come) and jQuery iPhone-like checkboxes:

In planning the architecture for the rewrite we considered (briefly) using CSLA.NET. CSLA implements authorization on a granular level down to property level access. In essence however this is still role-based authorization rather than permission-based authorization as ultimately Rocky suggests granting permissions by checking the IsInRole() method on the custom IIdentity object as follows:

public static bool CanAddObject()
{
return ApplicationContext.User.IsInRole("ProjectManager");
}

The authorization is then performed in factory methods.

public static Project NewProject()
{
if (!CannAddObject())
{
throw new SecurityException(
"User not authorized to add a project");
return DataPortal.Create<Project>(null);
}
}

Another limiting factor in the CSLA.NET implementation is that if you require permissions at a service layer rather than a domain layer then it requires you to write your own implementation on top of the existing CSLA.NET framework, which is far too fragmented a solution.

Eventually I came across an authorization security framework by Ayende called Rhino Security. The great thing about this solution is that it is completely extendible and can integrate in with most domain models (atleast it did for us). Rhino security is an authorization framework that is open to interpretation and implementation and this is why it is such a great solution. A one-size fits all solution is never going to work for an authorization framework as authorization itself is open to interpretation and is likely to be different across all enterprise software solutions.

I'm not going to go into great detail with Rhino Security, because that isn't what this post is about and also mainly because Ayende does such a great job in doing so here, here and here.

The following posts in this blog post series will go into detail as to how to integrate Rhino security into your ASP.NET application, including:

  • How to implement dynamic permissions discovery and automatic persistence
  • Page level security access using a httpmodule 
  • Feature and object level authorization
  • Creating the administration UI to control permissions