in reply to Re: How should I handle Orphan Sessions?
in thread How should I handle Orphan Sessions?

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.";
  • Comment on Re: Re: How should I handle Orphan Sessions?

Replies are listed 'Best First'.
Re: Re: Re: How should I handle Orphan Sessions?
by soon_j (Scribe) on Dec 20, 2003 at 06:33 UTC
    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: Re: Re: How should I handle Orphan Sessions?
by stvn (Monsignor) on Dec 20, 2003 at 17:21 UTC
    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