Auto logout by clearing session variable

BananaJim · March 26th, 2007, 04:04 AM

I am writing a classic ASP application that requires the user to log in. When logged in, a session variable is set that indicates that the user is logged in. Hence, the user remains logged in until they click the logout link or close the window.

An auto-logout can be done as soon as the user visits another page of the *same* site by including some ASP at the top of each page of the site that clears the session variable (althought I don't think this is the usual behaviour for a log-in site).

Question:

Is there a way to log the user out automatically as soon as they visit another web site (domain) within that window? If so, what is the reliability of it?

Thanks.

Raghunathan · April 3rd, 2007, 11:44 AM

hi,

u can handle the onunload event of the <BODY> where u call a javascript function in which you've to send a request to the server side asp page (using the location.href or xmlhttp), where you will be calling the Session.Abandon() function to clear out all the session variables and also if more things are to be cleared you can write the code to clean up the variables and DB connections in the Session_OnEnd() Event in the Global.asa file

hope this would help u out.. any further queries pls post here.. surely i'll try my best to help

Regards
Raghunathan

Regards,
Raghu

dparsons · April 3rd, 2007, 11:59 AM

That is not a favorable way to do this. OnUnload is called, for example, when you post a form or navigate to another page.

And your question all depends. If they leave your site through a link on your page that you have control over, it is easy enough to log them out when they click the link. However if the user physically types the new URL into the site, no, you can not log them out.

HTTP is a stateless protocol so when a user types in the new domain, there is no communication with your server to alert it that you are navigating to a new page outside of its domain.

I have a question though, why would you want to have such functionality? If this is a problem with cache, just set your pages not to cache. ^^

================================================== =========
Read this if you want to know how to get a correct reply for your question:
http://www.catb.org/~esr/faqs/smart-questions.html
^^Took that from planoie's profile^^
^^Modified text taken from gbianchi profile^^
================================================== =========
Technical Editor for: Professional Search Engine Optimization with ASP.NET
http://www.wiley.com/WileyCDA/WileyT...470131470.html
================================================== =========
Why can't Programmers, program??
http://www.codinghorror.com/blog/archives/000781.html
================================================== =========

BananaJim · April 3rd, 2007, 04:00 PM

The simple answer is: I don't want to do it.

My client (the in-duh-viduals) asked me if this could be done. Obviously, it's a stupid idea for a whole load of reasons, but I wanted to back it up with some technicalities. No need now, anyway, because the useability issues alone are enough to convince even the simplest in-duh-viduals not to consider doing it.

dparsons · April 3rd, 2007, 05:29 PM

I am not sure I agree with you whole-heartedly; it is true that what may seem simple or even trivial to a client may be downright difficult, if not impossible (though nothing is rarely impossible), from a pragmatic point of view.

If you go with the OnPageUnload angle, yes it is unuseable as you would log your user out everytime they tried to do something or navigate your site but, if i was sitting in a client meeting I wouldn't bring this up. It's a moot point.

Since HTTP is stateless you would need to devise a way to keep a "live" connection open to the server and once that connection is closed or broken, you know that the user has navigated away. The caveat to this is: if you keep passing data back and forth between client and server, your session will stay active so, regardless if the user has got up walked away from their pc, and left the office for the evening, your site is still up and this "live" connection is still active and hence the session is still alive. (This doesn't even take into account the bandwidth that would be consumed. Granted it would be a very small transfer but if 30 people did this, you can see how this could effect traffic and potentailly ballon into a problem)

So your problem isn't all together without a solution, it would just be a headache on your part and if the client is still hell bent on having this "feature" after hearing your argument against it well that is what they are paying you for: to provide them with what they want.

Anyway, thats my 2cents, good luck with your client.

================================================== =========
Read this if you want to know how to get a correct reply for your question:
http://www.catb.org/~esr/faqs/smart-questions.html
^^Took that from planoie's profile^^
^^Modified text taken from gbianchi profile^^
================================================== =========
Technical Editor for: Professional Search Engine Optimization with ASP.NET
http://www.wiley.com/WileyCDA/WileyT...470131470.html
================================================== =========
Why can't Programmers, program??
http://www.codinghorror.com/blog/archives/000781.html
================================================== =========

BananaJim · April 4th, 2007, 01:43 AM

"well that is what they are paying you for: to provide them with what they want."

Not always true by any means!

For example, my client has just requested that the entire rest of the web is barred from access while a user visits their site.

Of course, I told them I would make sure this was done, since they were, after all, paying me for it. ;)