I am not sure if this is the right venue for me to ask this question but I haven't found a discussion yet that can shed light to my problem.

Well, it isn't exactly a Perl problem...

Like perhaps having the ability to know if the client has left or his connection has been cut?

Nope. That you can't do. HTTP is stateless. You can provide him a logout link, but you won't know if he just decides to kill his browser.

Do you have any suggestions on how I can handle this?

If the user tries to relogin and already has a session but that session has been idle for X seconds/minutes/hours expire the session and start a new one else display a page saying that there is an active session. (Such a page might ask the user if he wants to expire it or tell him that he must wait.)

-sauoq
"My two cents aren't worth a dime.";

First of all, your session timeout length should be as short as you can possibly make it. There is no magic number here, it is really based upon how long your users are expected to be on a page before they next click on a link (and therefore renew the session and reset the timeout). This timeout value (of course) is stored in the database, and if it's value is shown to be in the past, then the session is expired and a user should be prompted to log in again. I find that 20-30 minutes is enough for most applications.

This takes care of old sessions, the double login issue is somewhat trickier, and you have a few choices. Assuming your session is somehow related to your user's account in some way, you can do it a few different ways.

1. You can force a new valid login to log-out any previous or current logins of the same user account. In turn forcing the expiration of the current session associated with that users account (and logging out the physical user associated it).

   The problem with this is that a potentially "stolen" login would kick out a "valid" login (or vice-versa). It provides no way to assure that a user is who they say they are, but truthfully, you can never really know this.

2. You can track the IP address (or some other machine identifier) of the current session somewhere in your database (or as a part of your session id somehow), and allow new logins from that machine address to override an orphaned sessions. For added "security", you can constrain this action within certain period of time (preferably shorter than the session timeout length).

   The drawbacks of this approach are again that you can never know if your user is truely who they say they are. The machine itself may have been compromised, or the IP spoofed. The problem might also arise if a user were to need to transfer machines because of a system crash or some other catostrophic event, they would need to wait out the session timeout. Since this is an extrordinary circumstance, this might be ok. Although things like DHCP and dropped dial-in connections could play havoc with this if you use IP addresses as your machine identifier.

3. There are always cookies. I personally do not like cookies for session management, I think they are clunky myself. But with cookies, you can have a dialog between the server and the client. If you do not set the cookie's expriation date, most browsers will consider closing the browser the expiration of that cookie. You can use this to take care of your "user closes browser but doesn't log out" problem. This however does not disallow dual-logins by itself, that needs to be a matter of policy in the database still.

   But there is no guarantee (that i know of) of these things working on all platforms/browsers so you will need to test it on your target platforms.

Alot of these issues should be discussed with your client/user-base to find out what is either the prefered method, or the method that conforms best to existing security policies.

Hope this helps in some way.

1. You can force a new valid login to log-out any previous or current logins of the same user account.

Oops. My browser window crashed. How can I go logout that session? Update: I misread that somehow. At least twice. Yes, you can do that. My apologies.

2. You can track the IP address (or some other machine identifier)

Ooops. My IP changes because my company uses a cluster of proxies... (What other machine identifier did you have in mind?)

3. There are always cookies. I personally do not like cookies for session management, I think they are clunky myself.

I assumed the OP was using cookies. This point doesn't really address his problem. By the way, if you are going to avoid cookies for session management, what alternative would you suggest is less clunky and why is it less clunky?

-sauoq
"My two cents aren't worth a dime.";

1. You can force a new valid login to log-out any previous or current logins of the same user account.

<That might work, but if I were the user, I do not want to be booted out from my session by someone who accidentally or not, just got my login information>

2. You can track the IP address (or some other machine identifier)

<This wouldn't work since the primary users of my website are students that might access the webpage from different internet cafes>

3. There are always cookies. I personally do not like cookies for session management, I think they are clunky myself.

<I haven't tried this approach. If I grab a cookie through $ENV{HTTP_COOKIE}, if the client closes his browser, would this variable be empty?>

As of the moment, I am setting my sessions to expire after an hour. I could probably try setting them to expire after X number of minutes that it is idle.

Thanks for the suggestions!
Jay Soon

RE: other machine identifiers

I suppose I was thinking of MAC address or something like that, which when i actually thought about it,.. would not be available through a web browser, so i guess i dont know of any other one. :)

RE: clusters of proxies and other such things

Your absolutely right on this one, it didnt occur to me, which is just dumb since that is exactly the set up I had at my last job, and it used to cause me no end of headaches. I guess i am just trying to block that part of my past out :P

RE: Cookies are clunky

I have a (probably) unfair bias against cookies, since I came from client side JS programming and migrated back to the server side. Back pre-5.0 browser, client side code for cookies was horrid, brittle and almost never cross-browser/platform. I developed a quick hatred of them. I have carried this bias along with me to my server-side programming.

As for what i feel is less clunky, I prefer to use hidden form fields for session management. Most of the applications I build for my company tend to be very form driven and the session id is only one of many bits of data I usually need to pass from page to page. As for raw HTML links, we use some creative javascript functions to minimize the headache of passing the session id on each link. Also, we exclusively use mod_perl handlers and have several URL filters to handle most other special cases.

Like i said, in the end, its more about what is acceptable behavior for your user base, or what conforms best to an existing securiy policy.

-stvn

Sure. You can use session cookie, which will be blown away when the user agent is closed.

Think about it, use session cookie (create a session cookie as session id), together with login id and IP address. To resolve your particular problem: if the same user login from the same IP address with no session id, just clear up his previous sessin context from the server, and let him login.

if the same user login from the same IP address with no session id, just clear up his previous sessin context from the server, and let him login.

Uhm, no. Multiple users can share one IP. The most common way this happens is with proxies. Similarly, a single user might appear to come from multiple IPs over successive requests. (Think proxy farms.) The IP is not reliable and your solution does not address his stated problem. Unfortunately, there is no real clean solution to it. The bottom line is that you really have to rely on the authentication credentials. That's really not so bad, though.

-sauoq
"My two cents aren't worth a dime.";

This is how I did it, just to give you an idea:

1. Verify if username exists in the database. If it exists, fetch the encrypted password.
2. Compere Passowrd with the decrypted password from the database.
3. Generate a session id. It is an encoded result of a username and expiration time.
4. Generate HTML through CGI with the session_id included as part of QUERY_STRING.

Every page that is accessed looks for the session id, decodes it, and if it is valid and not expired, generate the pages desired.

Though I stored IP addresses in a log, I did not include them in the validation since I'm aware of the higher chances that my users would be using their accounts on different machines (with different addresses).

Would this work.....

#Generate the HTML and Dump Cookie (session_id)
&generate_html();

#A function that checks for the Dumped Cookie. If it can't find the cookie it means that the USER_AGENT is closed.
&loop_to_check_for_cookie();

Also, being connected is a red herring. First of all HTTP is stateless, so there is no such thing. And even if there was a real connection, it wouldn;'t mean much, since the user could just have kept the old browser connected even if he's not behind the computer.

So I'd simply assume that a new session means the user moved, and just invalidate the old session. If imposter avoidance is impotant, give the user a message that you did so, so that the user (who supposedly knows he used the program recently somewhere else or not) gets a chance to decide if there is an imposter or not. In the scenario you started with where the imposter is working at the same time, the session will probably move between the two parties several times, and each will be aware of the existance of the other.