 |
General .NET For general discussion of MICROSOFT .NET topics that don't fall within any of the other .NET forum subcategories or .NET language forums.  If your question is specific to a language (C# or Visual Basic) or type of application (Windows Forms or ASP.Net) try an applicable forum category.
** PLEASE BE SPECIFIC WITH YOUR QUESTION **
When posting here, provide details regarding the Microsoft .NET language you are using and/or what type of application (Windows/Web Forms, etc) you are working in, if applicable to the question. This will help others answer the question without having to ask. |
Welcome to the p2p.wrox.com Forums.
You are currently viewing the General .NET section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
|
|
|

July 24th, 2004, 03:26 AM
|
Registered User
|
|
Join Date: Jul 2004
Posts: 3
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
DUPLICATES NOT ALLOWED
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
|

July 24th, 2004, 02:47 PM
|
 |
Friend of Wrox
|
|
Join Date: Aug 2003
Posts: 5,407
Thanks: 0
Thanked 16 Times in 16 Posts
|
|
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?
|

July 25th, 2004, 10:45 PM
|
Registered User
|
|
Join Date: Jul 2004
Posts: 3
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
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
|

July 26th, 2004, 08:11 AM
|
Friend of Wrox
|
|
Join Date: Jun 2003
Posts: 540
Thanks: 0
Thanked 4 Times in 4 Posts
|
|
Actually, the moderators on this forum are very good about posting :)
What about using .IsClientConnected to verify that your users are still connected?
J
|

July 26th, 2004, 09:45 AM
|
 |
Friend of Wrox
|
|
Join Date: Aug 2003
Posts: 5,407
Thanks: 0
Thanked 16 Times in 16 Posts
|
|
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.
|

July 26th, 2004, 02:29 PM
|
Friend of Wrox
|
|
Join Date: Jun 2003
Posts: 540
Thanks: 0
Thanked 4 Times in 4 Posts
|
|
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
|

July 26th, 2004, 10:32 PM
|
Registered User
|
|
Join Date: Jul 2004
Posts: 3
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
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
|

July 27th, 2004, 08:36 AM
|
Friend of Wrox
|
|
Join Date: Jun 2003
Posts: 540
Thanks: 0
Thanked 4 Times in 4 Posts
|
|
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
|

July 27th, 2004, 12:38 PM
|
 |
Friend of Wrox
|
|
Join Date: Aug 2003
Posts: 5,407
Thanks: 0
Thanked 16 Times in 16 Posts
|
|
I think you answered the question yourself. :)
Quote:
quote:Originally posted by katsarosj
So this is really only useful when the current page is still processing, correct? Once it stops processing, it is useless
|
How would you execute the IsClientConnected() method if the page isn't processing  ;)
|

July 27th, 2004, 03:05 PM
|
Friend of Wrox
|
|
Join Date: Jun 2003
Posts: 540
Thanks: 0
Thanked 4 Times in 4 Posts
|
|
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
|
|
 |