The full text of the error is:
Invalid postback or callback argument. Event validation is enabled using <pages enableEventValidation="true"/> 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.
I got this error when I built a gridview and did a databind for that control in the Page_Load event for the page. The databind() fired every time Page_load fired -- including on postbacks. I fixed the problem by making it so that I only do the databind on initial load of the page, e.g., when "IsPostBack" is false. The gridview's values are otherwise preserved in ViewState.
What's probably going on is this. The gridview's RowCommand event, which handles the postback event in this case, fires after the page's Page_Load event (naturally). So, in the error case, I was destroying and rebuilding the control on postback. So .net then compared the control that fired the postback to the "new" rebound control that was going to handle the postback event, and decided that they were different, and got haired up over a suspected cross-page scripting attack, hence the error message.
FYI, setting "enableEventValidation=false" as cautiously suggested by the error message doesn't work. The error goes away, but the postback event doesn't fire -- probably because this doesn't resolve the underlying issue, that .net is confused about what control is supposed to be handling the postback. In all likelihood, .net basically doesn't find any handler for the postback event, and it drops out.
So, the way I resolved this is, I no longer allow the control to be rebound on EVERY page_load. I only rebind it on the initial page_load, that is, "if not IsPostback." I don't have to rebind the control on every postback anyway, since its full state is maintained in viewstate.
Print
posted @ Sunday, March 09, 2008 10:40 PM