- Is the above technique is good to handle such scenario?
"Good" is subjective, of course. But this scenario should be fine. There are multiple ways to handle user tracking, and I'm curious if anybody has any concrete suggestions.
- How and where can I check for the session existence in unified place?
What I would recommend is abstracting the Session part of the user tracking into a common object in the application. Within that object you would check if the Session is null, check if the user is logged in, respond accordingly, etc. Then all of the pages (child and master) should just use that object.
This presents a couple of benefits:
- You only have to write the Session logic in one place. So you're not constantly writing conditionals on the Session all over the application. The rest of the application just calls methods on a common object.
- If you later want to move your user tracking from Session to something else (a database, for example... I've used things like RavenDB and MongoDB to track transient web application data in the past with good results), you only have to change one class. The rest of the application still continues to just use that common object.
For example, the class could have something like this:
public static string GetCurrentUsername()
{
if (Session["Employee"] == null)
throw new SomeKindOfAuthenticationException();
return ((EmployeeObject)Session["Employee"]).Username;
}
Then throughout your application you'd just call the user tracking object to GetCurrentUsername. And in Application_Error you'd handle your authentication exceptions by redirecting to a login page. (This is generally considered to be better practice than, say, returning an empty string in the method above for unauthenticated users. An empty string would have to be checked for constantly throughout the application, whereas the exception handling can happen in a single place. If you need a specific page to not redirect to the login page in this case but rather just not display something, wrap the call in exception handling local to that page and handle it accordingly.)
Consider, of course, that this is mainly a high-level design conjecture and I'm not referring to an actual implementation in front of me. Maybe being static will cause problems with Session? Maybe you need to pass it the Session? Where should you store this class? What other error checking should you do? And so on.
- Is it possible to trigger a method once a session ends?
Not reliably, in my experience. Consider all of the ways in which a Session could end. A user could click a "logout" link which has logic to clear a Session, or they could just abandon the browser, or their connection could fail for an extended period of time, etc. Web applications are passive request/response systems. Responding to a session timeout without user interaction is tantamount to an active ongoing server-side process, which web applications aren't suited to do.
This is actually one of the reasons why I've experimented with storing this transient data in a database. That way I could have a separate process (such as a Windows Service... something that is designed to run constantly in the background without user requests) monitoring that database and responding to things accordingly. One of the things that can be done in such a setup is a kind of manual Session_End. A separate process would poll the database for Sessions which haven't seen activity in X minutes (by checking a time stamp on an activity tracking record, for example) and respond by clearing the relevant data and performing any other tasks.
In my opinion this fairly cleanly separates the responsibilities of the web application (responding to user requests) and the state tracking (maintaining server-side data).
