in reply to How should I handle Orphan Sessions?

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.

-stvn
  • Comment on Re: How should I handle Orphan Sessions?

Replies are listed 'Best First'.
Re: Re: How should I handle Orphan Sessions?
by sauoq (Abbot) on Dec 20, 2003 at 04:34 UTC
    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.";
[reply]
      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
[reply]
        Thanks for the suggestions!

        Please note that those were not my suggestions. I was replying to stvn and quoting his suggestions whereas you are replying to me.

        Just the same, now that I reread his first bullet, it is essentially the same as my inital suggestion minus an idle time check.

        As I mentioned in my reply to pg in this thread, you really must rely on the authentication credentials you get. Your concern about booting someone off just because someone else got his login information is a bit misguided. That's exactly why someone has login credentials in the first place. If two people have the same login, there is no way for you to tell which one is authentic. Don't bother second guessing it.

        -sauoq
"My two cents aren't worth a dime.";
[reply]
      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
[reply]

In Section Seekers of Perl Wisdom