Error Readout:Exception: System.Web.HttpException
Message:
Authentication of viewstate failed. 1) If this is a cluster, edit
configuration so all servers use the same
validationKey and validation algorithm. AutoGenerate cannot be used in
a cluster. 2) Viewstate can only be posted back to the same page. 3)
The viewstate for this page might be corrupted.
Source: System.Web
at System.Web.UI.LosFormatter.Deserialize(String input)
at System.Web.UI.Page.LoadPageStateFromPersistenceMedium()Fix:
I encountered the above error the other day. Since the server wasn't on
a web farm I was a little confused. The fix I ended up using was
updating the web.config key to
requiressl=trueExplanation: The next
thing I asked myself was how can that key affect the viewstate. With
some serious investigation into viewstate and best practices I finally
made the link of how our applications viewstate is tied to session
state which is tied to SSL
when the session cookies are encrypted manually, a step (encrypting our own
session cookies manually) we did because we are still running asp.net 1.1.
How to manually encrypt the sessionid in a cookie
Response.Cookies["ASP.NET_SessionId"].SecureLets
dive right into how session state and viewstate work to get a better
understanding of the solution. ASP.NET session state lets you associate
a server-side string or object
dictionary containing state data with a particular HTTP client session.
A session is defined as a series of requests issued by the same client
within a certain period of time, and is managed by associating a
session ID with each unique client. The ID is supplied by the client on
each request, either in a cookie or as a special fragment of the
request URL.
[
http://msdn.microsoft.com/en-us/magazine/cc163730.aspx]
In
.net 1.1 there is a property called "ViewStateUserKey" located in the
viewstate, this key adds user-specific information to the view state.
When the request is
processed, ASP.NET extracts the key from the view state and compares it
against the
ViewStateUserKey
of the running page. If the two match, the request is considered
legitimate; otherwise an exception is thrown. In our application we use
the Session.SessionID to set the property. This is where my problem starts.
When
a user fills out a form utilizing viewstate to create an account to
login to our system the user establishes a viewstate in their asp.net
page. In order to make the view state slightly more secure we give the
viewstateuserkey
the same value as the session ID. The session ID is a much better fit
because a session ID is unpredictable, times out, and varies on a
per-user basis
[
http://msdn.microsoft.com/en-us/library/ms972969.aspx]
Once the user has completely filled out the form, we authenticate them. This is where my error occurs [See beginning of post].
The
error is caused because the session id is now encrypted. It's encrypted
because our security team said, all information stored in cookies is to
be secured. Our team consequently set up a flag in the global.asax file
that states if this flag is set to true it should grab the session id
out of each cookie and encrypt it. The reason we did this by hand
is because asp.net 1.1 does not offer secure cookies with one easy key
change in the web.config [NOTE: In asp.net 2.0 all you have to do is have the requiressl=true and you are done].
Now understanding that our session ID is tied to our viewstateuserkey you can understand the viewstateuserkey
is now invalid because the session ID is a different value, simply
because it's encrypted and the server does not know to decrypt it.
[
NOTE: The session ID may still be the same value, it's just
encrypted.] Now asp.net states the viewstateuserkey is invalid and pumps out the error you have seen above.
To
fix this I simply change requiressl=true in the web.config. How does
requrie ssl affect an encrypted session id within a cookie that I set
to encrypt? Well, when requiressl
is not on but you are sending the server a secure cookie value, which
we did since we created our own secure cookies in asp.net 1.1 the
server doesn't know to decrypt the cookie because requiressl is not turned
on [
apparently you have to send secure cookies over ssl in asp.net 1.1 and possibly other run times, I didn't know this] which in turn invalidates the viewstateuserkey because the viewstateuserkey uses the session ID which is encrypted in the secure cookie.
What
made
this confusing for me is the first part of the form worked without
a hitch. It's when the user authenticates when the error arose. The
reason for this being that the requiressl key is not applicable until
authentication happens. If you'll notice the requiressl key is nested
in the authentication element in the web.config file. Additionally we
don't encrypt the cookie until the user is authenticated. Sooo, the
first few postbacks for our page were just collecting information. It
wasn't until we authenticated the user to our system that requiressl
actually cared if we had secure cookies or not.
OverviewViewstateuserkey is set to the session ID.
Session ID is encrypted and the updated value is set to the viewstateuserkey
requressl
being turned on tells the server to decrypt session id in which case
allows the viewstateuserkey to remain valid with the server.