Article
One Community, One World
ASP.NET Client-Based State Management, Part02: View State
by Ahmed Rafie  on Jun 11 2007 12:00AM
  PageViews 2951   |    Add to Fav   |     Send to Friend   |    no downloads available
Introduction
In the first part of this article, we have explained hot to work with cookies. In this part we will continue the client-based state management option and look what is view state and how to write and read data from it, and explain all the view state consideration. Finally take a look at the security issues when using view state.

View state
View state is the method that the ASP.NET page framework uses by default to preserve page and control values between round trips. When the HTML for the page is rendered, the current state of the page and values that need to be retained during postback are serialized into base64-encoded strings and output in the view state hidden field. You can access view state in your own code using the page's viewstate property. This property is a dictionary containing key/value pairs containing the view state data.

View state consideration
  1. It provides state information for a specific ASP.NET page. If you need to use information on more than one page, or across the web site, you should use another method for maintaining state. Other than view state.
  2. Because viewstate information is serialized into XML and then encoded using base64 encoding which generate large amount of data. If view state contains large amount of data, it can affect performance of your page.
  3. In data-driven pages that are refreshed from the data store on each post back, you should turn view state off to remove the large hidden field generated by data controls such as grid view control.
  4. Some proxies and firewalls will prevent access to the page that contain large amount of hidden fields.
  5. Some mobile devices do not allow hidden fields at all, therefore view state will not work for these devices.

How To: Save values in view state
To use the view state property, the ASP.NET web page must have a server form element 

C#
Void Page-PreRender(object sender,EventArgs e) 
    {                                 
        Viewstate.add("TestData","testingviewstate"); 
    }



Since view state is sent as hidden fields, Changes to view state can be made until the PreRenderComplete event; once the page is rendered to the browser changes to view state will not be saved.

How To: Read values in view state
The Following code example shows how you can get an ArrayList:                

C#
ArrayList MyArray = new ArrayList ( );                                            
MyArray  = (ArrayList )ViewState["userinfo"];



No exception is thrown if you attempt to get a value out of view state that dose not exist. To be sure that the value you want is in view state, check first for the existence of the object.               

C#
If(ViewState["font"] != null


Advantages of using View state:

  1. No server resources are required, because view state is contained in a structure within the page code.
  2. View state has simple implementation and does not require any custom programming to use it. It is on by default to maintain state data on controls.
  3. Enhanced security features, because the values are hashed, compressed, and encoded for Unicode implementation, which provides more security than using hidden fields.

Disadvantages of using View state:

  1. Performance considerations, because view state is stored in the page itself, string large values can cause the page to slow down when users display it and when they past it.
  2. Device limitation, mobile devices might not have the memory capacity to store a large amount of view state data.
  3. Security risks, although view state stores data in a hashed format, it can still be tampered with, the information in the hidden field can be seen if the page output source is viewed directly.

View state chunking
View state data can become very large, in some cases. Because view state data is stored in hidden fields, some proxies and firewalls will prevent access to the pages that contain them. So ASP.NET 2.0 framework introduced a feature called view state chunking.

View state chunking is the process of splitting the data into chunks and put the data into multiple hidden-form fields, instead of transferring the data in large blocks.

To enable view state chunking, set the "MaxPageStateFieldLength" property to the maximum size that you want to allow in a single view-state field. When the page is postback to the server, the page parsers the view-state string at page initialization and restores property information in the page. The default setting is -1, which means that there is no maximum size and view state will not be broken up into chunks.

Security in View state
View state is stored on the page in a hidden field and is encoded using base64 encoding. In addition, a hash is created from the data using a machine authentication code MAC key. The hash value is added to the encoded view state data and the resulting string is stored on the page. When the page is postedback to the server, the ASP.NET framework re-hashes the view state data and compares the hash with the hashed stored previously in the page. If the hash dose not matches an exception is raised indication that view state data might be invalid.When ASP.NET framework creates a hash for view state data. It uses a MAC key that is

  1. Auto-generated.
  2. Specified in the Machine.Config file.

If the key is Auto-generated, it is created base on the MAC address of the computer, ASP.NET uses SHA1 encoding to create a large key. In a web-form environment, the key must be the same across all the servers. If the key is not the same, and the page is postback to a different server than on that created the page, on exception will be raised. So you should specify a key I machine.config instead of Auto-generation.

Encryption
While MAC encoding helps prevent tampering with view state data. It dose not prevent people from viewing this data in two ways

  1. Transmitting the page over SSL: This will prevent data-packet sniffing and un-authorizing access.
  2. Encrypting the view state data because SSL decrypts the page to display it in the browser, you should en encrypt the view state data, because these data might contain sensitive information such as SSN or IDs.

To encrypt the data, set the page's ViewStateEncryptionMode property to true, and the page handles all encryption and decryption for you.

Pre-user View state encoding
If your web site authenticates users, you can set the ViewStateUserKey property in the Page-Init event handler to associate the pages view state with a specific user. You must set the ViewStateUserKey to a unique value for each user, such as the user name or identifier. This will prevent one-click attacks in which a malicious user creates a valid, pre-filled page with view state data previously created page. The attacker then lures a victim into clicking a link that sends the page to the server using the victim's identity.

Comments