页面事件验证失败发生在一种环境中，而在另一种环境中不发生

Question

I am getting a rather standard event validation error under a particular set of steps with our web app:

Application_Error intercepted exception: Exception of type 'System.Web.HttpUnhandledException' was thrown.
System.Web.HttpUnhandledException: Exception of type 'System.Web.HttpUnhandledException' was thrown. ---> System.ArgumentException: 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.

The real headscratcher is that this is happening in our test environment, but not my development environment when I try to re-create. I've perused our web.config for things that might have changed, but I don't see anything that jumps out. The code is completely the same between the environments - TeamCity made certain of that. So I'm strongly suspecting an environmental problem, but I have little idea of where to start with something like event validation. That is typically handled in code.

Does anyone have an idea for a path to investigate on this? I realize some of the details of what I'm doing are sparse, but that is because everything works 100% fine in our development environments and there are no issues at all, so I don't know what would be relevant and what wouldn't. If more details are required, please ask and I will be delighted to provide them.

Answer 1

Presumably you've checked the enableEventValidation attribute in your config file - by default this won't exist. But it could very well be in the machine.config on one or both machines, resulting in a different configuration for that option.

Answer 2

For posterity, this was the situation.

We have a few dropdown lists that are populated via information from the HTTPWebSession cache. Great. We also have an AJAX partial postback at one point during our work flow, because we have to do some server side validation of user input without screwing up everything on the screen. Still no problem.

The problem occurs when this partial postback returns, and attempts to use some CSS classes that link to images that no longer exist in our project. The images were moved. This returns 404s. You'd still think this isn't an issue as long as the code isn't actually USING these images. And it's not.

The PROBLEM is that, in our testing environments, a 404 is a 404. It simply returns that, no big deal. In our production environments, we redirect 404 errors to our login page, because it's a bad user experience and it's not good to implicitly reveal what does and doesn't exist. This is the environmental factor.

...Because we work in a high-security environment, the login page wipes the cache as part of its PreRender, so it doesn't matter if it was actually loading the page graphics or not. Ergo, an AJAX partial postback wiped the cache, which made the session-loaded information in the dropdown list -- which is not updated by the partial postback! -- not expected input. And, perfectly reasonably, Event Validation refused to accept this input on the full page submit.

This strange and complex problem was solved...by deleting a CSS class.