Session State v ViewState

Question

In our application, we have a "BasePage" that declares a number of properties to be used by more or less every page in the app.

Inside these properties, they write to ViewState. These are all typically an int or small string value, nothing huge. Typical use is call a web service and hold an id for use within the page, for example.

I've used viewstate since I'm wary of the loss of session variables should IIS recycle for example. Also, I figured, very small values would not add hugely to the page size.

Am I being overly paranoid about session though and would it have been a better option.

Our environment is a 2 server cluster with SSL termination on each server, sticky sessions maintained by the load balancer - so using In Proc is not a problem per say, I'm just very wary of it.

Answer 1

I think it's best to avoid using Session state where possible, especially on a server cluster even if you are using sticky sessions. Sessions can expire, or disappear when IIS recycles (like you said).

I'd go with keeping the values in ViewState or a cookie.

Answer 2

If it is not sensitive data, I would also prefer to store it in the HTML rather than the session.

Answer 3

Never trust your user sent data.

Even all data you receive is not sensitive, if you send it to your user browser, you should to check it again before use it. Maybe most users are legitimate, but just one can break your application.

What are your options to store data?

• Hidden field; can ve easily tampered at client side
• Cookie; ancient method to keep user specific data, but very size limited.
• ViewState; your data go to client and come back, using bandwidth and could be tampered.
• Session, InProc; your never have problems, until a application pool get recycled
• Session, State server; you keep your session data in another server process.
• Session, database; can work with almost (if not all) load balance scenarios, as you dont need stick sessions, nor to worry with app pools recycling. All your data are belong to us your SQL Server.

Reading your scenario, you probably need to deal with out-of-process session storage.