[EMAIL PROTECTED] wrote:
> How are you handling your sessions? I use Apache::Session::Postgres.
I'm using AuthCookie. A customization of AuthCookieDBI to be specific.
However, I also use Apache::Session. Basically, I authenticate
with AuthCookie, then I pass the authenticated username over to
Apache::Session::File (for now, probably soon to become A:S:Postgres)
and use the user id as the session key. In that session I store user
preferences, etc...
> In my scenario, if I needed to do this, I would check the list of valid
> sessions I have for one that exists for the user. ie, if 'gphat' tries to
> login, I check to see if any of the sessions the db are for user gphat. If so,
> eliminate it and create a new one.
I can also detect if the user had an existing session already (I store
the AuthCookie key in the db for each user). However, the question is
just because there's an existing AuthCookie key, it doesn't mean they
have another active session. It could just be an expired one. So, it
seems the logic would go something like:
1. User logs in
2. Check for another session key for this user
3. If found, check to see if it's expired.
4. If not expired, alert user and ask if user wants to expire older session
5. Expire older session
It's #5 that's troublesome. I wasn't sure how I could expire the older
session (since the session key that matters is sitting client side). I
guess I could keep a table of invalidated session keys, and check
against that every time in along with all the other checks going on in
authen_ses_key(). I was just mainly asking if there was an existing
solution out there.
The main requirement that we're trying to solve is that a user cannot be
signed on from more than one location at once. Mainly because this
probably means that they walked away from a computer with an active
session on it, which isn't good. I suppose an inactivity timer might be
helpful, too.
Thanks,
Fran
