Puzzled about viewstate error

[jeff29_b]

We have in our site the pages tag in the webroot tag like so.

<pages enableViewState="true" enableViewStateMac="false" />

But we are still getting errors during
LoadPageStateFromPersistenceMedium.

The stack trace is like so -


at System.Web.Configuration.MachineKey.GetDecodedData(Byte[] buf,
Byte[] modifier, Int32 start, Int32 length, Int32& dataLength)

at System.Web.UI.LosFormatter.Deserialize(String input)

I thought, that if enableViewStateMac was false that it wouldn't try
and decode the data and just base64 encode the view state so the above
method getdecodeddata wouldn't be called. Or am I wrong on that?
Also, we have the same machineKey in the file in the server farm.

 

[Bruce Barker]

enableViewStateMac = false, just turns off using the servers's mac address
as part of the encryption key. you can gererate your own key, and place it
in the config (as must be done for a web frame).


-- bruce (sqlwork.com)

 

[jeff29_b]

I don't think that is correct. I have already generated my own
encryption key using the machineKey tag in the web.config.

According to the documentation,
"EnableViewStateMAC - Specifies whether ASP.NET should run a message
authentication code (MAC) on the page's view state when the page is
posted back from the client. A view state MAC is an encrypted version
of the hidden variable that a page's view state is persisted to when
sent to the browser. If true, the encrypted view state is checked to
verify that it has not been tampered with on the client."

My interpretation is that if this is disabled it doesn't encrypt the
viewstate that is set to the hidden variable, hence, getdecodeddata
shouldn't be called.

 

[jeff29_b]

Addendum: Here is the text from msdn on the machineKey entry

"Specifies the key used for validation of encrypted data. validationKey
is used when enableViewStateMAC is true to create a message
authentication code (MAC) to ensure that view state has not been
tampered with. validationKey is also used to generate out-of-process,
application-specific session IDs to ensure that session state variables
are isolated between sessions."

 

[Bruce Barker]

but if you look at the code (aways the source), you will see its always
encrypted, there are just 3 encryption methods, and ways to set the keys.

-- bruce (sqlwork.com)

 

[jeff29_b]

No, that isn't correct. It isn't encrypted it is base64encoded. There
is a difference there one you need a machinekey to decode with the
other one you don't.