ASP.NET Session lost after Response.Redirect problem? You may just need to clear your cookies.

If you develop in ASP.NET soon or later you have come across a very annoying problem: the Session is lost after a Response.Redirect.

This is a such random problem that puzzled me and my colleagues in several occasions for quite long time.

Let's take for example the following snippet:

Session.Add("UserID", 1234);
Response.Redirect("/default.aspx", false);

This is adding the value 1234 to the UserID Session variable and then redirects the request to the default.aspx page. Note that the false parameter indicates that the Response should not end abruptly, instead the redirect will occur after the Page life cycle has loaded completely.
Bertrand Le Roy's article explains very well the reason why this is wise to do and I suggest you to read it if you haven't done yet.

So if you are still having the Session problem despite you are allowing the entire Page life cycle to load, then probably the problem may be much simpler than you think!


Basically the problem may well be related with the browser's cookies. In fact clearing you cookies may solve it!

Cookies are the mean by which a session can persist across different requests, the browser is identified each time through the session ID stored in a cookie.

I didn't have time to investigate what is exactly occurring, I'll spare this for next time when I'll update this post.

Singleton pattern in ASP.NET applications

  

Some years ago I remember I spent quite some time while trying to debug a cross session contamination of data.

The problem ended up being due to an improper use of the static modifier in the context of ASP.NET applications.

In fact, in ASP.NET,  static objects are instantiated one time for each application domain, and all processing in the application share the same object, while at that time I understood that the static modifier acted within the page life span!

For this very reason, a Singleton pattern that relies on a static object will be most of the times useless if the wished behaviour is to have its life span limited to the page life cycle: a static object is always shared across the entire application!

In my own experience, when I require a single instance of an object I most often want its scope and life cycle to be within a web request or single session and in very few occasions to be application wide.

I decided I was going to create a helper class that would allow me to instantiate a Singleton instance of an object and being able to decide its scope.

I put together a Singleton helper class and 3 persister classes: one for the Session, one for the Page life cycle and one for the Application.

The persister classes would define the singleton life span and scope so that if I wanted to have a single instance of MyObjectClass with a life span of a single web request I could easily get an instance of it in the following way:

MyObjectClass o = Singleton<MyObjectClass, ItemsPersister>.GetInstance();

Likewise within the session life span:

MyObjectClass o = Singleton<MyObjectClass, SessionPersister>.GetInstance();

And application life span:

MyObjectClass o = Singleton<MyObjectClass, ApplicationPersister>.GetInstance();

The Singleton<T, S> has T which is the type of the class I want to have a single instance of, and S the type of the Persister that I wish to adopt.

Here is the singleton helper and the persisters full code:

    public class Singleton<T, S> : ISingleton
        where T : new()
        where S : IPersister, new()
    {
        public static T GetInstance()
        {
            var identifier = new T().GetType().Name;
            var persister = new S();
            var instance = (T)persister.Get(identifier);
            if (instance == null)
            {
                instance = new T();
                persister.Set(identifier, instance);
            }
            return (T)instance;
        }
    }

    public interface IPersister
    {
        object Get(string name);
        void Set(string name, object o);
        void Remove(string name);
    }

    public class SessionPersister : IPersister
    {
        private HttpContext _Context;

        public SessionPersister()
        {
            this._Context = HttpContext.Current;
        }

        public object Get(string name)
        {
            return this._Context.Session[name];
        }

        public void Set(string name, object o)
        {
            this._Context.Session.Add(name, o);
        }

        public void Remove(string name)
        {
            this._Context.Session.Remove(name);
        }
    }

    public class ItemsPersister : IPersister
    {
        private HttpContext _Context;

        public ItemsPersister()
        {
            this._Context = HttpContext.Current;
        }

        public object Get(string name)
        {
            return this._Context.Items[name];
        }

        public void Set(string name, object o)
        {
            this._Context.Items.Add(name, o);
        }

        public void Remove(string name)
        {
            this._Context.Items.Remove(name);
        }
    }

    public class ApplicationPersister : IPersister
    {
        private HttpContext _Context;

        public ApplicationPersister()
        {
            this._Context = HttpContext.Current;
        }
        public object Get(string name)
        {
            return this._Context.Application[name];
        }

        public void Set(string name, object o)
        {
            this._Context.Application.Add(name, o);
        }

        public void Remove(string name)
        {
            this._Context.Application.Remove(name);
        }
    }

Please note that my solution is forcing a bit the concept of Singleton pattern. This pattern generally has the class that we want a single instance of, responsible for generating its own instance; this class also has only private constructors to guarantee that an instance of it can be created only within itself.

My main aim was not to reinvent the Singleton pattern but to provide a simple way of creating a single instance of a class within a chosen life scope.

If you are not familiar with the Singleton pattern please refer to http://en.wikipedia.org/wiki/Singleton_pattern for a more in depth explanation of the Singleton pattern.

Thanks for reading.

User input validation architecture

I've recently built an online hotel booking interface that integrates with a third party booking system.
Since this third party system will be most likely used for future projects I tried to design each component as generic as possible so that they can be reused.

The specification required a series of validation rules to be applied to user input. These rule varied from maximum length of stay to how far ahead in time a booking can be made and I was sure they would have changed with time and will definitely change when we integrated the same system for other clients.

I implemented them as separate modular layers on top of the basic functionality. For maintainability and modularity I wanted to avoid to implement them as as series of nested if statements which are harder to maintain.

What I wanted to achieve was:

1) Implement one or more rules independently

2) Rules should be reusable for other projects

3) If a rule fails the workflow should handle the notification to the user interface

4) Client side (Javascript) validation rules and Server side (ASP.NET) validation rules should be expressed in one single place.

5) Code structure should be simple to understand and quick to grasp for fellow programmers.

6) Extract a generic and reusable library to accomplish similar validation.

Since recently I've been reading Design Patterns Explained: A New Perspective on Object-Oriented Design, Second Edition that goes through the GOF patterns, I decided that I wanted to chose from the patterns discussed in the book to solve my problem.

One of these patterns is the Decorator pattern, which is used to dynamically extend (decorate) the functionality of an existing object.

In fact the Decorator pattern uses polymorphism to extend the functionality of an existing object allowing to stack several decorator classes on top of each other, each time adding a new functionality to the overridden method(s).

I decided that this pattern was a good candidate:

The user interface component that holds the form fields(in this case a .NET UserControl)  will be responsible to collect the user inputted data from the form collection and initialise a UserInput object.

The UserInput class would have the followings:

- bool IsValid();

- void Validate();

- List Errors { get; set;} //Error is a simple object extending the System.Exception object

The UserInput object would be responsible for performing the basic data validation which is checking that the inputted data can be parsed from String to its final type ( ie DateTime, int etc)

The UserInputDecorator decorator abstract class would implement the UserInput interface and expose the followings:

- UserInput _UserInput{get; private set;}

- UserInputDecorator(UserInput ui) { this._UserInput = ui; }

- abstract bool IsValid();

- abstract void Validate();

- List Errors { get; set;} //Error is a simple object extending the System.Exception object

Now a series of classes can be derived from the UserInputDecorator to add validation functionality to the base class.

These classes are for example:

- UserInputDatesAreSequential //Asserts that the start date is prior to the end date

- UserInputMaxStayLength //Asserts that the max stay is less than a client defined one

-UserInputMaxAheadBooking // Asserts that the booking is no more than certain days in future

- UserInputValidHotelCode // Asserts that the HotelCode is valid

Using the Decorator pattern I could then stack up the various validations in the following way:

UserInput u = new UserInput(start_date, end_date, hotel_code);

u = new UserInputDatesAreInRightOrder(u);

u = new UserInputMaxStayLength(u);

u = new UserInputMaxAheadBooking(u);

u = new UserInputValidHotelCode(u);

u.Validate();

if(!u.isValid())

{

//Extract list of errors and display them to the user

}

This way I was able to extract the rules and make them generic validation rule.

The combination of these rules creates a client specific set of rule.

I can run Unit Testing because each Rule is isolated and does not depend on the user interface's User Control.

The client side validation was accomplished by wrapping these rules with a web service that the Javascript queries when rules need to be enforced within the browser.

This seemed to me a neat way to accomplish rules validation. I'm not a big fan of nested if statements because they are hard to maintain as their number increase.

Instead with this approach the code remains simple and readable, unit testable, modular and reusable.

Thanks for reading.