many people logging in using same user name

[Michelle Stone]

Hi everybody

I am writing a simple asp.net application using form
authentication. I store the list of all users and their
passwords in an SQL Server database table.

My client recently told me that he wants me to do
something through which only one user can login using any
given account name. I mean to say, for example, when a
user called "abc" is online, another person shouldn't be
allowed to login using the same login.

I thought of many possibilities. I am listing down some
here, along with some reasons why I am reluctant to use
them. If there is any better way, or if you have comments
on any of the following, please share them with me.

1. Use a field in the table called "bLoggedOn" and set it
to true when the user is on.

Problem: How can I know when the user is logged out? What
if the modem-line connection is cut in between? Or what
if the server crashes for five minutes?

2. Use an Application variable (perhaps an array or
something....fyi, the maximum number of users online at
any time is 50). But then again, how can I "log off" a
user if his connection is cut?

In any of the following cases, one thing is very
important. If he closes the browser and attempts to
relogin, he shouldn't get the message "you are already
logged on from another location." The users will be at
the frontdesk of an office and they can't wait for a few
minutes before the server automatically logs them off.

I need to know whether there is any way the server can
know when a guy logs off.

Thanks....

<oops, looks like this message got a bit too long >

 

[Patrice Scribe]

As http is connection less, the best you could do is to have an explicit way
to logoff (and hope the user is using it). Other than that you just have the
usual timeout mechanism that will end a session when the timeout period
ellapsed without any user activity.

You could also trap some unload event client side to be able to
programmatically "abandon" the session (and probably a problem for example
if you have multiple windows) but this is working against the architecture.

A last option would be to disable the existing session so that users are
always able to log on (but existing sessions wuill be suspended).

It could be interesting to see why exactly having a unique account logged at
any one time is a requirement to see if this is not a way to solve another
problem he is thinking about ?

Patrice

 

[Cowboy \(Gregory A. Beamer\)]

Hi everybody

I am writing a simple asp.net application using form
authentication. I store the list of all users and their
passwords in an SQL Server database table.

My client recently told me that he wants me to do
something through which only one user can login using any
given account name. I mean to say, for example, when a
user called "abc" is online, another person shouldn't be
allowed to login using the same login.

I thought of many possibilities. I am listing down some
here, along with some reasons why I am reluctant to use
them. If there is any better way, or if you have comments
on any of the following, please share them with me.

1. Use a field in the table called "bLoggedOn" and set it
to true when the user is on.

Problem: How can I know when the user is logged out? What
if the modem-line connection is cut in between? Or what
if the server crashes for five minutes?

With web apps, there is no way to know, as the client is stateless. The best
you can offer is to log the session ID and key it to the user. Then, you can
query whether the session is alive and delete the tie to the user. If a user
tries to log in again, they will be refused. You will store, SessionID,
UserID and TTL (time to live) in the database. Every hit increases time to
live. Formula: TTL = CurrentTime + NumMinutesForTimeOut

Pros
Tied to the session methdology MS uses
Rather simplistic to create

Cons
Database has to be tied to session time out, so you have to chance the
timeout time in two places
If a user's machine crashes, they are locked out for 20 minutes

2. Use an Application variable (perhaps an array or
something....fyi, the maximum number of users online at
any time is 50). But then again, how can I "log off" a
user if his connection is cut?

Nothing will help you here.

In any of the following cases, one thing is very
important. If he closes the browser and attempts to
relogin, he shouldn't get the message "you are already
logged on from another location." The users will be at
the frontdesk of an office and they can't wait for a few
minutes before the server automatically logs them off.

Then, you cannot do it. At least not with a web application.

One compromise here. When a user logs on, store his IP address, UserName,
SessionID and a TTL. Give the TTL of about 1-2 minutes, rather than the 20
the session times out. This will stop the user from opening one session and
immediately opening another, but will not stop those who wish to wait. If a
user pops out of a browser, he will only have to wait 1 minute to get back
in.

To stop users that want to open multiple sessions, tie the UserID to
whatever record they are working on. Opening more than one session will not
allow them to bounce between records any faster than only having one. This
will further discourage people from bucking the system.

I need to know whether there is any way the server can
know when a guy logs off.

Using normal web app methodology? No!

You can build an aware web app, but you will end up with one or more of the
following:

1. Slow performance
2. Extremely difficult code
3. Increased network latency due to chattiness

Thanks....

<oops, looks like this message got a bit too long >

It's OK, I do it occasionally too! ;->

Here is the scoop. Browser communication over HTTP is stateless. Each time
the client wants a page, he requests. In between the server has NO CLUE the
browser did not become the victim of a nuclear war. The whole concept of
Session is artificial, and is a method agreed on by browser manufacturers
and web server manufacturers to give some form of state to stateless
communication. As the server does not KNOW what the client is doing, it sets
up the session and assumes the user is in session until the session times
out. You can slide the timeout up or down, but that is the only control you
have.

In your app, you might be able to slide the session way down, but you would
have to use something other than forms auth to auth the user or they will
have to log in very often, which will annoy them. This is probably a
NON-solution. So, you kludge out a method of stopping a user from logging in
that is separate from session. But, the time has to be very short, which
means a user can, theorhetically, wait a minute and open another session.
So, you have to make that a stupid proposition. Keying the user to whatever
record he is working on is an option. Normally, I hate this type of kludge,
but you have to see if the client will compromise.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

**********************************************************************
Think Outside the Box!
**********************************************************************

 

[Munsifali Rashid]

I have used the first option in the past with limited success. For this to
work successfully, it is very important that you catch when the user is
logged out. You can run code in the Session_OnEnd event to reset bLoggedOn
to false. However, one problem with this, is when the user closes the
window without logging out. Working around this takes a little more work.
Use a single frame frameset which contains the application. In the onUnload
event of the frameset, run some code to log the user out. When they close
the window, it will popup a little box in the background which will log them
out. This should execute very quickly, and will almost be transparent to
the user.

E.g.

Your frameset page would consist of the following:

<script language="javascript">
function window_onunload()
{
window.open("http://www.domain.com/autologout.aspx", "logout",
"width=100,height=100,status=no,toolbar=no,menubar=no,location=no");
}
</script>


The frameset could consist of the following:

<frameset rows="100%" onUnload="window_onunload()">
<frame name="MainFrame" src="default.aspx" marginwidth="0"
marginheight="0" scrolling="auto" frameborder="0">
</frameset>


The "autologout.aspx" page would have something as follows (C#):

private void Page_Load(object sender, System.EventArgs e)
{
// Code to log the user out here

// Script to close window
string strCloseWinScript = "<script
language='JavaScript'>self.close()</script>";

// Register the script, so that the window closes
Page.RegisterStartupScript("closewin", strCloseWinScript);
}


Hope this helps,

Mun

 

[Mohamed El Ashamwy]

Following up on Munsifali's message, you could use the window_onunload event
to call the autologout.aspx without using the window.open jscript method.
You could use the xmlhttp object to call the logout page and in such case no
new window will be opened when the user unloads the html page.

Ex.

<script language="javascript">
function window_onunload()
{
var xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
xmlhttp.Open("POST", "http://www.domain.com/autologout.aspx",
false);
xmlhttp.Send(xmldoc);
}
</script>

This code will call the logout page without openning a new page. However, it
needs the client browser to be IE version 5.0 or higher (I hope this won't
be a conflict with your requirements).

One Important Point to note here:
The onunload event is called also when you try to refresh the web page. This
means that the refresh would cause the onunload event to fire. You should
detect whether this is a refresh before sending the request for the
autologout.aspx

Regards
Mohamed El Ashmawy

(e-mail address removed)

 

[Kevin Spencer]

Hi Michelle,

Whaty I would do is to create a Collection or Array in the Application Cache
(this can be done during the Application_OnStart Event Hander). Then, in the
Session_OnStart Event Handler, add the user id of the current logged-in user
to that Collection. You can then check that Collection whenever a user tries
to log in. In the Session_OnEnd Event Handler, remove that user from the
collection.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.