Page Inheritance In ASP.NET

• Download sample project - 33.5 Kb

Introduction

The advent of ASP.NET arriving in a world that up to that point had become accustomed to VBScript or JavaScript spaghetti code was the introduction of true, or truer, object oriented programming (OOP) paradigms to web page development. We have seen over the years how to apply objects to facilitate web components and controls within ASP.NET applications to automate the process of building out a functional web solution with minimal code. One of the most overlooked features of object orientation, however, is utilizing inheritance with the base System.Web.UI.Page class.

The most important advantage base Page inheritance gives is the ability to enforce security across all pages that take advantage of the inheritance. You can even specify varying user access levels per page with only one line of code and one tweak of code. The tweak involves replacing the web form’s declaration with an inheritance of a new semi-abstract class called CommonPage rather than System.Web.UI.Page.

// Create a new .cs file with a CommonPage class declaration

public class CommonPage : System.Web.UI.Page
{
    // ...

}

// Replace the standard inheritance declaration of any new web form

// with a reference to CommonPage

public class WebForm1 : CommonPage // changed ": System.Web.UI.Page"

{
    // ...

}

By moving to our own base class type, we are now able to customize the base functionality of every web form that inherits this base type, simply by modifying CommonPage.cs. In this way, all pages subscribing to this base class can also be guaranteed to expose and make available certain properties and methods not as easily available in the previous base class, such as application-specific page, user, or session properties. We can also enforce security checks and clean-up routines that are common across all participating pages.

Specifying Minimum Access Levels

The natural initial progression of extending CommonPage is to first enforce security. We can guarantee through inheritance and a simple security access level declaration that no user can access a particular page without proper security clearance as long as the page inherits CommonPage rather than System.Web.UI.Page. This is achieved by customizing the constructor of CommonPage and the Load event of System.Web.UI.Page, and thereby executing a new AccessCheck method before the web form ever executes.

public CommonPage() {
    base.Load +=new EventHandler(CommonPage_Load);
}

private void CommonPage_Load(object sender, EventArgs e) {
    AccessCheck();
}

private void AccessCheck () {
    // enforce security here ...

}

At this point, it is now possible to customize the access levels of each page with only a single line of code per page. In order to do this, we must first define a set of access levels with an enum called AccessLevel.

public enum AccessLevel {
    Guest = 0,
    BaseMember = 1,
    FullMember = 5, // numerically spaced for future expansion

    Administrator = 10
}

With AccessLevel defined, we can now specify a simple field in the web form called MinLevel that identifies the clearance level required for the particular web form. Normally, one would override a “MinLevel” property declared in CommonPage and customize its get method.

public class WebForm1 : CommonPage
{
    protected override AccessLevel MinLevel {
        get {
            return AccessLevel.FullMember;
        }
    }
    // ...

}

This is, of course, considered the most correct way of customizing an access level customization on an inherited web form. However, in order to make this only a single line of code, we can break the paradigm of using overridden properties and instead use a constant field. In our case, our goal is to eliminate as much coding as possible, including even any method or property blocks. So, we instead declare a simple field in the web form that specifies the minimum access level.

public class WebForm1 : CommonPage
{
   public const AccessLevel MinLevel = AccessLevel.FullMember;
   // ...

}

In order for CommonPage to retrieve this value, it must use the System.Reflection namespace to discover the value.

// Figure 1

public class CommonPage : System.Web.UI.Page
{
    private const AccessLevel DefaultMinLevel = AccessLevel.Guest;
    private void AccessCheck() {
        AccessLevel minLevel = DefaultMinLevel;
        System.Reflection.FieldInfo fi =
            this.GetType().GetField("MinLevel",
            System.Reflection.BindingFlags.Public |
            System.Reflection.BindingFlags.Static |
            System.Reflection.BindingFlags.FlattenHierarchy);
        if (fi != null) minLevel = (AccessLevel)fi.GetValue(null);
        // ... 

    }
    // ...

}

Now, CommonPage knows the minimum access level for the page. We also specified a DefaultMinLevel constant to be sure that new inheriting web forms that do not have a MinLevel specification can default user access limits to this value. In this way, we can make the default access level FullMember, for instance, so that by default no new inheriting web form is accessible by anyone except that level of user.

Exposing a Common User Object

Now that we have specified an access level for a page, we need to have CommonPage map the user’s AccessLevel. The best way of doing this is to create a whole new user object and keep it stored in the session at all times. We will create an AppUser class and have its default AccessLevel property set to Guest. Then we will expose this object as a Session-stored property in CommonPage that is accessible as CurrentUser.

// Figure 2

namespace InheritenceSample
{
    public class AppUser
    {
        public AccessLevel Level = AccessLevel.Guest;
    }

    public class CommonPage : System.Web.UI.Page
    {
        // ...


        public AppUser CurrentUser {
            get {
                AppUser usr = (AppUser)Session["AppUser"];
                if (usr == null) {
                    usr = new AppUser();
                    Session.Add("AppUser", usr);
                }
                return usr;
            }
        }
    }
}

At this point, it is very easy for AccessCheck method in CommonPage to determine whether the user does not have access to a particular page, with this boolean evaluation:

if (CurrentUser.Level < minLevel) { // ...

By default, an AppUser object’s level is Guest. You can customize the AccessCheck method so that all Guest users attempting to access a more secure page are redirected to a login page that would modify the user’s access level according to a value specified in a database. In the login page, you can use Request.ServerVariables[“HTTP_REFERER”] to return to the referring page after logging in, or you can pass a more appropriate custom URL in the query string that redirects to the Login page, and have the Login page default to one and override to the other.

Going Further

In addition to applying security, this paradigm makes all new pages derived from your CommonPage class universally conformant to the parameters you specify in a single class, or in a few subclasses. For example, you can create a CommonXPage class that inherits CommonPage, and inherit CommonXPage only in web forms that do function X, so that these have a common minimum security level or a common task to perform when loading, and so forth.

We can also establish universal clean-up routines that are common to all pages in our application, by using the Unload event in CommonPage. (Note that utilizing deconstructors in ASP.NET, or “~CommonPage() {…}”, is not recommended.)

public class CommonPage : System.Web.UI.Page
{
    public CommonPage() {
        base.Load += new EventHandler(CommonPage_Load);
        base.Unload += new EventHandler(CommonPage_Unload);
    }

    private void CommonPage_Unload(object sender, EventArgs e) {
        // common clean up ...

    }
    // ...

}

All of the benefits of inheritance in object oriented programming apply in ASP.NET. Hopefully, we have only scratched the surface as to what levels of productivity you can take web application development to using inheritance in ASP.NET and making the most of OOP methodologies.