Client-Side Data, List Boxes, and EventValidation

Somewhat of an old topic, but still merits covering given the seemingly-overwhelming ignorance on the subject.

A common layout for a configuration page in some applications involves having a list box full of potential values and another list box adjacent from the first containing active values. In between the two list boxes are buttons which are responsible for providing functionality that allows us to move an item from the potential pool to the active pool. Not the most exciting thing, and fairly basic in and of itself, but you may run into an issue if you use something like JQuery to do the moving of the items (most would agree that having to do it with a postback instead would be rather painful).

Specifically, you may find yourself seeing the following error message if you perform a postback following the moving of one or more items from the potential pool to the active pool:

Invalid postback or callback argument. Event validation is enabled using in configuration or <%@ page enableeventvalidation=”true” %> in a page. For security purposes, this feature verifies that arguments to postback or callback events originate from the server control that originally rendered them. If the data is valid and expected, use the ClientScriptManager.RegisterForEventValidation method in order to register the postback or callback data for validation.

The reason why you are getting this is because the data being added to the active list box is being submitted from the client-side, and isn’t something that server has put there. The server is not prepared to validate this data, and because this could potentially be dangerous and unwanted data, we get the previous error thrown at us.

There are a lot of examples and forum posts online that say the best thing to do is to simply turn off event validation using <%@ page enableeventvalidation=”true” %>. Doing this essentially turns off an important layer of security ASP.NET is providing for us. I find it irresponsible to recommend this solution, and would lead me to believe someone was incompetent if I ever saw them doing it without also adding thorough alternative input validation.

The correct way to handle this is to register the control receiving the client-side data (the active item list box) for event validation. In order to do this, you need to register an event reference for validation with a unique control ID with the potential values it may receive included. It should go inside a Render override. Something like:

    protected override void Render(HtmlTextWriter writer)
    {
      ClientScript.RegisterForEventValidation(ActiveListBox.UniqueID, ...);

      base.Render(writer);
    }

The ellipsis above represent the potential values. Most examples online demonstrate the use of hardcoded values as the potential values. I’ve never come across a list box containing values known at compile with anything I’ve worked on. So what you want to do, in our example, is loop through all of the list items in the potential item list box, and register those for event validation.

One important thing to note is what property’s value from the potential list items you should be registering. Don’t register the ListItem.Text property; something I bet some might do as a simple mistake. Register the ListItem.Value property instead. Taking all of that into consideration, you’d probably want something like the following:

    protected override void Render(HtmlTextWriter writer)
    {
      foreach (ListItem item in PotentialListBox.Items)
        ClientScript.RegisterForEventValidation(ActiveListBox.UniqueID, item.Value);

      base.Render(writer);
    }

That’ll take care of your problem then! If you are ever having errors relating to bad postback-data, you can always view what’s being submitted by temporarily overriding the Page’s ProcessRequest method and looking at the provided context’s Request property while developing your solution.validation.