i had bought a web domain online where i am hosting asp.net website's/web-application's.
Many a times I am facing an error:
Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster......
After a long research i had found that the error occurs due to "Application Pool Idle Timeout".
By default an app-pool will recycle every 5 minutes. If this recycle happened while a user is busy on the site and send post back to the server, the server no longer recognizes the session/viewstate and rejects what is being posted back.
My "Application Pool Idle Timeout" value is around 5 min. which is too short.
i had contacted the domain person to change the timeout period but they refused to do so saying its same for all and cant be changed.
I had googled for other solutions and found the below solutions:
Setting the EnableViewStateMAC property to false (Not good w.r.t. security reasons).
Provide your own validation and decryption keys "" (Doesn't work).
Please provide me a better solution ASAP.
Or Should I change the domain manager (like godaddy.com).
I have seen and resolved this issue in past. This issue majorly comes when you host application on Web Farm or web Cluster.
When a page is rendered, its view state is encrypted on server and sent to client. When page is posted back, this view state data is decrypted on server to get the state of the page. For Encryption and decryption of viewState server uses some keys, which if not provided in Maching.config files, are generated on the fly by server.
If you are on a single server hosting environment, these keys might get recycled. But on a Web Farm or Web Cluster, if these keys are generated at random then they are different for every server, and a request from one server can be posted back to another server that has different set of key and where it fails.
Solution to this is Adding MachineKey entries to all the server's Machine.Config files, or to your application's web.config files so that each server uses same keys for encryption and decryption of view state.
Related
I have 8 host behind LB and all of them are single process(not web garden). Despite setting all of them with the same machine key from iis as shown below, I'm still getting Invalid viewstate exception rarely.
There similar questions but none of them helped me(I've no server with pending updates or restart as in the other questions or i'm not using server.execute etc). So please don't flag as duplicate. Are there any alternative ways to prevent this exception?
Thx
Normally, This is because of the difference in Machine keys in different servers. We use Web Farm for High availability. In this case, if a Client sends a request then the Load balancer decides, which webserver to serve the request. It happens several times that another request might be served by another server. So here is the issue.
As we know, view stat is Client-side state management techniques and the data travels with the request and response. So if the view state is encrypted with some machine key and in other requests if handled by another server and that has different machine key, it would not be able to decrypt it and will through the error.
Every server generates a new key when it is set auto. and even sometimes any recycle of the app domain will generate a new key when it is set to auto. It means we cannot use the default auto-generated key. So here the solution is to use a specific key in the machine.config to prevent automatic key generation on each process start.
One another flexible approach, however, would be to add a MachineKey section to the web.config file of your web site. This would not require to make the changes on every web server.
another way is you could try to set below code in machine.config:
enableViewStateMac="false"
I have a asp.net website that is deployed on two servers. In front of the servers there's a load balancer that distribute requests to the two servers. To store the session we use SQL Server.
My problem is that if the user go to the page, press a button and then by the load balancer happens to be routed to the other server that request wont be recognized as a postback? Why is that, shouldn't it work just fine even with postbacks as long as the servers share the same machine keys?
Details:
Both servers have the same machine key configured, and I verified that the actual session is the same on both servers by a small debug page I made that sets and prints out a session object.
To further verify the keys and Id I printed out the values of HttpRuntime.AppDomainAppId and a hashed machinekey (MachineKeySection)ConfigurationManager.GetSection("system.web/machineKey") and the sessionId Session.SessionID and got the same output on both servers. I used Session Debug page as a base for this. Its output looks something like this (I replaced my actual machinkey hash and session id with dummy values):
Current DataTime: 2012-07-20 10:52:58
Current Session Mode: SQLServer
HttpRuntime.AppDomainAppId: /LM/W3SVC/5/ROOT
Hashed with the MachineKey: HjtOPW5dfoihdlkd+SdsfkEWfs0=
Local Machine Name: 127.0.0.1
Current Session ID: 2alsudhsdkjlhcmnsdfkhsdf
The ID for the site, found in IISMgr under Advanced Settings on the site is the same on all servers.
As long as I stay on the same server everything works as expected.
When I run the page locally (first request to web farm, then route second button click to localhost by fiddler), I get the same behaviour
Stepping through the code and reading up on the IsPostBack property it seems my problem is that this._fPageLayoutChanged on the Page is true. However, if I understand things correctly it should be false when a postback happens? SO Question on its implementation
Both servers run IIS 7.
Both servers run Windows Server Web with SP2 and the same windows update updates installed. My local dev machine on the other hand runs Windows 7.
Turns out that adding a manual entry of the Machinekey in the web.config fixed the problem. Very strange as I checked its global value and also the hash as detailed in the question but now it works.
I take that back. After our last release the problem is back, so the machinekey addition did not help at all.
I'm having a problem of losing session variable on my website. It append at random times so there is no particular behavior that cause this. What can be the cause of this session lost?
I've read everywhere on this site that I could put my session in "sql server" mode so everything is written on the server, can it be a solution?
My server is on 1and1 shared hosting, can it be their fault?
Thanks !
Check with the hosting provider that your application is not being hosted on a load balanced server. If the server is being load balanced, your users will lose their session state information when the load balancer sends their request to another server. There are 3 settings Session State mode property:
InProc - Will store state information locally on the server from which the request is made (only effective when the application is being hosted on a single server in a non-load balanced environment)
StateServer - Allows a specially configured server to host state information for an entire web farm (I believe StateServer began to be offered on .NET Framework v2.0).
SqlServer - Allows a specially configured SQL Server instance to store session information for a web farm
[This information will vary slighty in a web garden scenario.]
See MSDN for more information on Session State.
This can happen very randomly based on their load balancing settings (think: sticky load balancing) and can work for several minutes one time and fail almost immediately another time.
The other possibility is the timeout property of the sessionstate setting in the web.config has been set to a low value (it is in minutes) and the session is expiring.
I am getting the follwing error,please tell me why this error is coming
Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that <machineKey> configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster.
this can happen when you post a form which in the meantime has been updated on the server, or the app has been recycled in IIS.
By default Viewstate is generated based on the MAC address of the machine that the web server is running on - this can cause problems when load balancing web traffic across a web farm or cluster as there is a chance that a pages post back request might get processed by a different machine from the one that originally generated the viewstate token, which will cause the exception that you see above.
If your running a web farm / cluster then the answer is the <machineKey> configuration element - if you set this to the same algorithm / key for each of the machines then viewstate is generated based on this key instead of the MAC address of the machine, preventing the above problems.
This blog article probably explains it better than I just did.
I'm having a problem with a web app I'm managing. Users starting receiving the following error occasionally:
Validation of viewstate MAC failed. If
this application is hosted by a Web
Farm or cluster, ensure that
configuration specifies
the same validationKey and validation
algorithm. AutoGenerate cannot be used
in a cluster.
The problem is that it's not a cluster - it's a single Windows 2003 server. After digging around, it appears that adding a machineKey section and some extra attributes to the Pages directive in my web.config resolves this error:
<machineKey validationKey='MACHINE KEY SNIPPED'
decryptionKey='DECRYPTION KEY SNIPPED'
validation='SHA1'/>
<pages validateRequest="true" enableEventValidation="false">
After changing these two things in my web.config, the error goes away, but now I have a new problem - Instead of an error that my viewstate is invalid, the app just "Forgets" who my user is, and sends them back to the login page. Now, the users are browsing through the application, and then they're unexpectedly sent to the login page, even after they've already been logged in for a few minutes. While I can't force this to happen, it usually happens within visiting 10-12 different pages, so pretty frequently.
I'd love a resolution to this - does anybody know what else might be causing the viewstate error on a single server, or what I can do to ensure that it's validated properly?
It sounds as though the worker process is recycling itself (assuming you're storing session state in-process). Picking a fixed key means that the viewstate is still valid when the process comes back up, but you've lost the session state. You could try storing the session state in a database, but I'd be more concerned to fix the underlying problem. Does your application suddenly allocate vast amounts of memory, or anything like that? Is there anything suspicious in the event log?
It turned out that this began happening when I added additional worked processes to the app pool that was running our application. Because the session state was being stored InProc (and not in a state service or a SQL Server), it was losing track of who the user was when it switched them between working processes. For now, dropping the number of processes on our server back to one corrected the problem, since raising it didn't seem to have any improvement in the first place.