Is it possible to save view state on the web server

Instead of saving the new viewstate, that is generated by action2, it would keep the viewstate, generated by action1, which can cause unexpected behaviour when loading the viewstate later in the Load method. It seems to me that the proper handling is if the vsKey is found in the cache, a new key with a new file should be generated.

Unfortunately, it seems that the previous cache file can't be just deleted, since the user can go back several times, and access an old page, which viewstate has been removed from the cache. But probably the auto-expiry of the cache is a good enough, here. Ivan Mitev. Re: Issues when using the browser Back button? Did you manage to solve this "back button" issue and make it consistent Ivan? I've seen you made some neat fixes here in the comments! Thank you Prashant Trambake Jun Prashant Trambake.

Thank you man Thanks a million! Hi, Thanks very much for a comprehensive post. It helped me out of a hole that I've been trying dig myself out of for what seems like an age Although, finding out that the very large ViewState in my application was the source of the problem is what took up the vast majority of time Thanks again Ben.

Works great! Just one problem we are seeing This is the best solution we've found to reduce the viewstate on our pages. We've been using it for a couple of weeks, and the performance on our site is way better, specially on slow connections.

There's an occasional problem we are receiving: Copy Code System. IOException: The process cannot access the file '.. This has happened only 3 times randomly in this 2 weeks. Has anyone received this type of error, or knows how to avoid it?

Thanks in advance. Re: Works great! A question too. It looks really great! One question. When I use it on a page that has ASP. Is it an expected behavior? Thanks and regards Navin. Broken link druffyw 8-Aug Seems that the "doh Random errors using page.

Cache maurolo 9-Feb Hi, this idea of using the controlAdapter configured in the. I'd like to share a couple of ideas. To avoid the two tabs problem we changed the code and created a new GUID for the page it's less readable but it's certainly unique instead of using the page name, ticks etc Anyway sometimes, randomly, if we use the CachePageStatePersister we get an exception here: if string. The fact is that if we switch to the SessionPageStatePersister insted everything works fine with no exception.

But then maybe the problem is in the page cache lifetime Cache to HttpRuntime. Cache and now everything works perfectly! Any thoughts about it? Re: Random errors using page. Cache Kalpesh Desai Oct Article is really very good and Idea of storing ViewState on server is more optimistic but after implementation we too have same problem with Page.

Cache mechanism. It doesn't seem to be reliable, within last 16 hours, we had more than 12, errors of this type. I am not sure why cache gets flush before it's expiry. We don't even use Forms based authentication case explained above. I am going to switch to HttpRuntime. Cache but like to know what's difference between these two ways in terms of performance and reliability. Thanks, Kalpesh. I wanted to make a note of a security flaw in your implemention.

As you may have guessed, we have been reviewing our code for security flaws at work a lot lately. If you try to get a value out of view state that does not exist, no exception is thrown. To make sure that a value is in view state, check first whether the object exists. The following example shows how to check for a view state entry.

If you try to use a nonexistent view state entry in some other way for example, to examine its type , a NullReferenceException exception is thrown. By default, view state data is stored in the page in a hidden field and is encoded using base64 encoding. In addition, a hash of the view state data is created from the data by using a machine authentication code MAC key.

The hash value is added to the encoded view state data and the resulting string is stored in the page. When the page is posted back to the server, the ASP.

NET page framework re-computes the hash value and compares it with the value stored in view state. If the hash values do not match, an exception is raised that indicates that view state data might be invalid. By creating a hash value, the ASP. NET page framework can test whether the view state data has been corrupted or tampered with.

However, even if it is not tampered with, view state data can still be intercepted and read by malicious users. The MAC key that is used to compute the view state hash value is either auto-generated or specified in the Machine.

If the key is auto-generated, it is created based on the MAC address of the computer, which is the unique GUID value of the network adapter in that computer. It can be difficult for malicious users to reverse-engineer the MAC key based on the hash value in view state. Thus, MAC encoding is a reasonably reliable way to determine whether view state data has been changed. In general, the larger the MAC key that is used to generate the hash, the less likely it is that the hash value for different strings will be the same.

When the key is auto-generated, ASP. However, in a Web-farm environment, the key must be the same across all the servers. If the key is not the same, and the page is posted back to a different server than the one that created the page, the ASP. NET page framework will raise an exception. Therefore, in a Web farm environment, you should specify a key in the Machine. NET auto-generate one. In that case, make sure that you create a key that is long enough to offer sufficient security for the hashed value.

However, the longer the key is, the more time it takes to create a hash. Therefore, you must weigh security needs versus performance needs. Although MAC encoding helps prevent tampering with view state data, it does not prevent users from viewing the data. You can prevent people from viewing this data in two ways: by transmitting the page over SSL, and by encrypting the view state data.

Requiring the page to be sent over SSL can help prevent data-packet sniffing and unauthorized data access by people who are not the intended recipients of the page. However, the user who requested the page can still view the view state data because SSL decrypts the page to display it in the browser. This is fine if you are not concerned about authorized users having access to view-state data.

However, in some cases, controls might use view state to store information that no users should have access to. For example, the page might contain a data-bound control that stores item identifiers data keys in view state. The control is an input control and it changes only from user actions. The control never changes. Next Recommended Reading. Windows 10 Vs Windows Visual Studio Vs Visual Studio Understanding Matplotlib With Examples. Understanding Numpy With Examples.

You must use relative path references when you use cookieless sessions. In this article I discussed the important and sometimes confusing essentials of state management. I explored the basics of state management and you learned about the different techniques available on the client-side ViewState , query strings, and cookies as well as on the server-side application state and session state.

I also discussed storing session state information in-process and out-of-process. In-process session state management involves storing session variable information in the same Windows process that ASP. NET is running in while out-of-process stores session state in another Windows service or on another machine completely. My Subscriber Account Advertise Write. Training Home State of. Staffing Home Looking for Staff?

Looking for Work? Contact Us. Dark Kimbie. Published in:. Filed under: ASP. Understanding State If you are familiar with Web development then you are well aware that developing Web applications is very different from developing Win32 applications. An application session starts when the first person accesses the application. Flipping the ViewState Switch On and Off You may have guessed that parsing the ViewState information can involve some serious processing on the server for a well-populated page.

Hitching a Ride on ViewState There may be times when you will want to send other information to the server along with the current page so that same information package returns when the page completes its round trip. If Not Page. Advantages of Using ViewState It is easy to implement.

It retains page and control state for you automatically. It does not use server resources since all of the state information is contained within the page itself. Disadvantages of Using ViewState Since ViewState information is stored in the page code itself, the potential for ViewState bloat exists for heavily populated pages or pages containing DataGrids.

Performance problems with ViewState can cause a page to display slowly and cause a delay when it is posted back. Page security can be a problem when using ViewState since the ViewState data is available in the page source and, even though it is encrypted, it can still be tampered with. Redirect method like this. Text One issue you likely encounter using Web Form control values is many browsers do not support blanks in a query string.

URLEncode txtName. URLEncode txtCity. Browser support for passing values in a query string is nearly universal. Disadvantages of Using Query Strings Query strings are insecure because the information in the query string is directly visible to the user on the address line in the browser Many browsers impose a URL character limit which can limit their flexibility. Client-Based Technique 3: Cookies Mmmmmm cookies and milk Session Cookies Session cookies are stored in-memory during the client browser session.

Add objCookie You read the cookie created above like this. Cookies "UserName". Value Persistent Cookies Persistent cookies work the same way as session cookies. Add objCookie You read a persistent cookie the same way you read a session cookie. Cookies "MyCookie". Value Cookie Dictionary A cookie dictionary is a single cookie that stores multiple pieces of information.

You create a cookie dictionary with code like this. Date objCookieDictionary. MaxValue Response. Add objCookieDictionary You retrieve a value from a cookie dictionary with code like this. Values "LastVisit" End If Advantages of Using Cookies Cookies are great for storing small pieces of frequently changing information on a user's machine. Cookies are easy to implement. Cookies do not require any server resources since they are stored on the client.

You can configure cookies to expire when the browser session ends session cookies or they can exist for a specified length of time on the client computer persistent cookies. Disadvantages of Using Cookies A user can delete a cookie.

A user can refuse a cookie. Cookies exist as plain text on the client machine and they may pose a possible security risk since someone or code with control of a user's computer can open and tamper with cookies. Paying Attention to Cookie Security You must pay close attention to the type of data you store in cookies.

Cookies are not designed to store critical information so storing passwords in a cookie is a bad idea. Keep the lifetime of a cookie as short as practically possible. Encrypt cookie data to help protect the values stored in the cookie. Client-Side Method State Management Summary Table 1 summarizes client-side state management techniques and when you should consider using them.

Server-Based Technique 1: Application State Now that you understand the client-based state management techniques let's explore the server-based state management techniques. You add values to the application state with code like this. Remove "ApplicationStart" You can remove all the variables from application state by using the RemoveAll method. RemoveAll Because application state variables are shared across the entire application, there is a possibility that multiple users could attempt to update the same application state variable at the same time.

Unlock You need to understand that an application session starts when the first person accesses the application. Server-Based Technique 2: Session State The second server-based technique involves using session state variables. You can add values to the session state with code like this. Remove "Company" You can remove the variables from session state by using the RemoveAll method like this Session.

RemoveAll A session starts when a user accesses a page on a Web site for the first time, at which time they are assigned a unique session ID. A Web server crash will lose all the current session data. You lose session data if the application is restarted for any reason.