Get Help:Ask a Question in our Forums|Report a Bug|More Help Resources
Last post Nov 06, 2012 02:20 PM by fimine
Nov 06, 2012 01:46 PM|LINK
Hi all (I am Winforms guy, so bear with me)
I am working on a asp.net project that is almost 9 years old. It was done in .NET 1.1 and I migrate it to .NET 3.5
Strange thing, how they did their session management. They have a super class that inherits System.Web.UI.Page and everytime a sub-page is loaded, they call UserSessionVerify method in the super class.
Which basically calls the database where a session ID is generated and maintained. This call check the database to see if the session is still valid. So basically when the user is idel for example 20 mins, and then comes back and clicks on anything, it calls
the page load and does the session verification.
Is this the right way to do? I don't want to change a lot of code, as this is in production and stable.
However, I want pages to timeout itself after 20 mins and be redirected to Login page, even if user looses their work.
Anyone see how this can be done given the above situation? Please let me know. Thanks.
Nov 06, 2012 01:48 PM|LINK
If you're in the base class and you've decided the session ID is no longer valid you can always call Response.Redirect to your login page.
Nov 06, 2012 02:09 PM|LINK
Please understand that everytime a subpage loads, in the page load method the super class method VerifyUserSession is called. This connects to the database to check if the session is valid, using session ID and the user ID. And then it does redirect to Login
However, my question was, if there is a way to timeout a page and redirect to login page automatically, if the user was idle for more than 20 mins.
Nov 06, 2012 02:20 PM|LINK
There are lots of better ways to implement this. It sounds as whoever built the original app wasn't fully aware of all the available features or options in ASP.NET. The suggestion I made was a solution with minimal impact on your current code. Unfortunately
the right way to implement what you're looking for introduces some larger changes to the app -- the impact will depend on how the rest of the app is written. My suggestion:
Don't use session for tracking the authenticated user. Session is not designed for security. Instead use forms authentication for tracking authentication. It then has a self-contained timeout mechanism and you don't have to write the code to check the timeout
or the redirect.
Also, I guess there is a reason for the solution they had before. This could have been a load balancing/sessoin serialization implementation (not known to windows forms guys :) ) If your site is run on a server farm/array or on at least two machines simultaneously,
you need to pass the session info between those machines. Say, it timed out on machine A, but the user was going through machine B... Unless you use sticky session you cannot know of the real timeout unless you store session info at a common location, DB being
one of the popular choices.