0

Our webapp's login page periodically gets hit with error events from corrupted viewstate. Why this happens doesn't matter -- some of it may be crack scripts or whatever. I've been told to eliminate these errors. First I turned off viewstate for the page. That still left a short __VIEWSTATE which may have been "empty" but still had structure. This did no good whatever in preventing the errors.

Then I overrode the page's SavePageStateToPersistenceMedium and LoadPageStateFromPersistenceMedium methods with no-ops. This eliminated all content in __VIEWSTATE... but that still didn't solve the error problem. The hidden field still exists in the page, and if you set any value into it before postback, it still produces exceptions that say "The state information is invalid for this page and might be corrupted."

The error is thrown by ClientScriptManager.ValidateEvent, which is called by TextBox.LoadPostData, or by HiddenField.LoadPostData if I have no serverside textboxes. I don't understand why it thinks it has to check for state when it is both deactivated at the page level and neutralized in the save/load phases, but it insists on doing so. Is there something I can overload to prevent this useless validation check?

My boss wants me to make this page ENTIRELY free of viewstate behavior, so it neither generates nor responds in any way to any form of viewstate-related data. He wants it to be impossible for any posted data to ever trigger any viewstate-related code. But all normal validations must remain in place for the rest of the app; changes are to apply to this single page only. How can this be accomplished?

[update] Another thing that doesn't work is to override the page's PageStatePersister method. I also tried preventing output of the hidden field in the page's Render method, but if I add it back for the post, the exception still occurs.

[update] ...I think my boss is now willing to give up on accomplishing this. But if anyone comes up with an answer, you certainly have my admiration.

Paul Kienitz
  • 878
  • 6
  • 25
  • I don't get it... as far as I can see there's no ClientScriptManager object on the client side, and there's no ValidateEvent property to the script manager on the server side. And will a JS tweak really prevent the server-side validation action? Seems unlikely. – Paul Kienitz Apr 07 '16 at 19:46
  • Sorry Paul, the ClientScriptManager is the server side object, was thinking of something else that was used by the ASP.NET AJAX stuff. – CodingGorilla Apr 08 '16 at 11:14

1 Answers1

0

You are looking at the Control State which happens to be saved inside the viewstate html field.

Control state is used for instance to store the pager information: https://msdn.microsoft.com/en-us/library/1whwt1k7.aspx

Decode it to have a look: How to decode viewstate

Community
  • 1
  • 1
Erik Oppedijk
  • 3,496
  • 4
  • 31
  • 42
  • I have already eliminated all the viewstate content, so there is nothing to decode. I am trying to eliminate the viewstate parsing, so it can't be disrupted by, for instance, a malicious fake hidden field. At this point I'll settle for a decent way to catch the errors. – Paul Kienitz Apr 08 '16 at 17:11