This is one of those posts I’m just putting out there in the hopes it saves some other poor programmer the hours and hours worth of headaches that we just went through.
When we were developing the new search control panel for Atomic Avenue, we set it up so that several of the dropdownlists fill up with data based on other selections. For instance, if you choose to search by artist, a list of artist names will appear to choose from. As it turns out, such data-driven fields—particularly if they’re not always made visible until a later action (such as indicating you want to search by Artist) unhides them—is a great way to generate “invalid postback” errors under Ajax. This is especially true if you combine them with the AddHistoryPoint method in Asp.Net Futures’ July release to enable Back Button support.
The problem is that the new security controls in ASP.NET 2.0 can’t validate that the postbacks on the page were generated by those controls in the first place since (a) the contents can change as a result of the postback, and (b) the event validation may not have been set up in the first place if the control in question was hidden to start.
For the best rundown on the issue, here’s the critical blog post by K.Scott Allen (check out part 1 as well)
Three options for getting around the situation presented themselves:
1. We could just disable the event validation checking, but that would open us up to new and fun injection attacks from folks faking postback data and using it to trick our web page into doing various inconvenient things. In particular, we didn’t want to do that with our search since it was meant as a system-wide facility, meaning it would be used on virtually every page in the system.
2. We could avoid Ajax altogether and use traditional, full-page HTML rendering. This wasn’t a good option for us, since the Ajax-enabled version is *much* faster (and better looking) than the traditional HTML architecture which would require full page redraws after every control selection.
3. We could try calling Clientscript.RegisterForEventValidation and supply all the possible values of each dropdown prior to validation, but since there were often thousands of possibilities, this was impractical in the extreme.
So what was there to do? The answer was to roll our own version of the Dropdownlist control, leaving out the (non-inheritable) SupportsEventValidation attribute. By replacing the three problematic dropdownlists with the new control (“DynamicDropdownList”), we were able to get things working (including back button support) without tripping all over this rather thorny problem.
-Pete
2 responses to “Stopping “Invalid Callback or Postback” errors when using Ajax with dynamically filled dropdowns”