How can I handle postback data after session timeout?

[Gaetan]

I have an ASP.Net 1.1 application using datagrid. I am trying to handle conditions where
the users post back an updated datagrid after the session times out. The results are not
pretty. Sometimes IE will report an invalid ViewState and sometimes my application will
generate a typical exception because the object reference has become null.

How does the experts and the rugged WEB applications handle or detect when the data
received from the browser is some left over from a previous session?

 

[Lars Netzel]

There are alternatives when storing the Session data... this will of course
be a little tradeoff on the Performance but you have store the session
information in other places...

If possible and the page is not too big already, then why not save the dataa
whithin the viewstate of the page?

Or if you really need to store it on the server.. Read about storing Session
data in a SQL database or thru the ASP.NET State Service

/Lars

 

[Gaetan]

I guess I can always go the extra mile and save state data elsewhere. Nevertheless, I
still need to determine when the postback occurs after the session expired.

I noticed that on a Session_Start() event, the Request.HttpMethod property is set to
"GET". After that, when the user takes an action on the web page which causes a post back
to the server, the Request.HttpMethod property is then set to "POST".

After a session timeout, if the user once more cause a post back, the Session_Start()
event is fired and this tim Request.HttpMethod instead of being set to GET, is not set
to POST.

Would a check on "POST" in a Session_Start() event be enough to detect a post-session
timout request?

 

[Guest]

Gaetan, I see you beat me to this.

This problem happens even when there is no datagrid. For example. Simple
form with a couple TextBox controls. Browse to the page, data appears in the
Texboxes. Wait until the session times out, change data in the textboxes and
submit the data... InvalidViewState exception.

 

[Bruce Barker]

the same thing happens on an application recycle. you should detect that
the session has been cleared and take corrective action.

the cheapest (not too profession, but better than crashing), to to redirect
to a recover page. this logic could be added to begin request in the global
application object.

-- bruce (sqlwork.com)