I am writing an ASP .Net Sales application. Can anyone suggest me a method to avoid simultaneous logins (e.g. User "anon" should not exist on two client machines)? Please consider conditions like power failure at client site. I do not want to catch any "close" events and then execute something. Because, in case of a power cut, that's not going to work.

Regards & cheers,

cOdEdRiLLeR

You are pretty limited with what you can do with an ASP.NET application. Usually you would store some value in session when the first login occurs. Then when a second login occurs, you check that value and deny login if it's still there. When the session times out (or someone actually hits a "logout" button) the value is cleared so another login can occur. However, if the client loses power or shuts down the browser without loggin out, another login can not occur until the session times out. Now, you could certainly set a very short session timeout but this would have adverse affects on a valid logged in user. They would need to maintain enough activity to keep the session active.

Unfortunately, due to the more passive and stateless nature of web applications you will be limited in what you can achieve.

Do you expect your clients to loose power on a regular basis?

I appreciate your response, planoie [Moderators generally DO NOT reply].

Yes. I do expect expect my clients to loose power on a regular basis. Actually, that is why this post exists. PLEASE suggest me a way that can provide a protection against duplicate logins. Can I use session_start/end in global.asax (I am using VB .Net)?

Thanks in advance.

cOdEdRiLLeR

Actually, the moderators on this forum are very good about posting :)

What about using .IsClientConnected to verify that your users are still connected?

J

ASP.NET is a web technology, therefore, for the most part (>95% of the time) the client is NOT connected. It's a stateless, disconnected environment. So using .IsClientConnected is rather pointless.

cOdEdRiLLeR-
I'm curious to hear why you expect your clients to loose power on a regular basis. (Perhaps purchasing some UPSs would be wise! ;))

But seriously, my previous post did provide you with a solution but it was wrong. I wasn't thinking "globally". I intended to suggest using an application value (not session, as session is user specific). You could also use the ASP.NET web cache. Perhaps you could store some table of users so you can check to see that a particular user is not already logged in. A hash table might be adequate for this operation. Store a hash table with the user ID as the hash table key, then you store that user's "login expiration" (DateTime) as the value. This way, then a user tries to log in, if the login is occurring before the "login expiration" value then you deny login. If the login is occurring after the "login expiration" then you permit login.

The more prominent point that I was trying to make is that with the disconnected nature of a web application, it's difficult to know when a user is truly disconnected. Maybe with the above solution, you can set up something so that the server is being "polled" by some means. Normally, you would do this with a hidden page (in a hidden frame) that refreshes on a regular basis. The page doesn't have to do anything except update the "login expiration" to Now + x minutes. This way, your login could be set to expire in a very short time (like 1 or 2 minutes) and this hidden page automatically refreshes every 45 seconds. This would keep the login active while the user's browser is open. Once they close it, the login would automatically expire after the "login expiration" time has passed. This would cover closing the browser without logging out and also a power failure. Then when the user tries to log in after their computer is back on (which should definately take more than a minute or two, especially in a power failure), the previous login has since expired and they will be permitted to log in again.

Well, it was rather early when I wrote that post.

Peter, if you would be so kind as to give an example of when .IsClientConnected would be beneficial, I would appreciate it.

When I posted the last message, I had read that it could be used to determine whether the client's machine was still connected. But I see your point. So this is really only useful when the current page is still processing, correct? Once it stops processing, it is useless?

________________________________________________

To the question, how about an Administrator tool that can reset all or some of the login/passwords in the event of a power outage? May not be as pretty as Peter's suggestion, but it is a suggestion...

J

Hey katsarosj,

I already have that provision in my admin interface bud. But... what if the admin is not in his seat to see whos on and whos not. Anyways. Peter's post (hidden refresh page) makes sense. I'll try Peter. I let you know ;).

cOdEdRiLLeR

OK,

It was just a thought. We have people who are on call if anything goes wrong (such as passwords needing to be changed or reset), so I was assuming that you would have something similar.

J

I think you answered the question yourself. :)

How would you execute the IsClientConnected() method if the page isn't processing ;)

Yeah, I guess I was just trying to envision an application that would take so long that it would need to verify that the client was still connected. Apparently, the recommendations for it's use are for processor intense applications (although, unless this is something where this is expected, it might irritate some people to have to wait that long...)

For anyone who is interested, Microsoft posted an example of this at:

http://support.microsoft.com:80/supp.../q182/8/92.asp

It uses classic ASP, but you should get the idea.

J