NYCPHP Meetup

[Jim Hendricks]

I had to deal with this whole situation a couple years ago with an ASP app,
but the principle should work with PHP.

At login the users loginID, SessionKey, and login time were added to a login
table.  The Session timeout was set to 3 minutes.  Each page in the system
contained a hidden frame with a page in it which was set to refresh at 2
minutes.  The refresh would update the login table for this user and session
to the current time and redeliver the same page, but this activity acts as a
heartbeat keeping the session alive. Since it's in a hidden frame, it does
not affect the active page.  This also has the affect of allowing a user to
stay on a page as long as necessary and not get arbitrarily timed out ( they
had one form in the system which took over a half hour to fill out ).

When a login attempt is made and an entry is found for that loginID the
current time is compared to the last activity time.  If the difference is
more than 4 minutes, the connection is assumed dead, the log entry is
archived, and a new entry created for this login.  If the login entry is
still considered active( user shut down the browser without using our logout
feature & right away attempts to log back in ) the user is provided a
message indicating that there is a current session for that userID also with
a message explaining that if that session was an improperly logged out
session from the same user than the login would be unlocked within 5
minutes.

Hope I recalled enough of the details to be useful, it has been a while
since I've needed this type of functionality.

Jim

______________________________________________________________
Jim Hendricks, President, Biz Computing, Inc
Phone:  (201) 599-9380     Email: jim at bizcomputinginc.com
Web: www.bizcomputinginc.com
Snail:  Jim Hendricks,  Biz Computing, Inc.,  255 McKinley Ave, New Milford,
NJ 07646
______________________________________________________________



----- Original Message -----
From: "Mark Armendariz" <nyphp at enobrev.com>
To: "NYPHP Talk" <talk at nyphp.org>
Sent: Thursday, February 27, 2003 1:37 AM
Subject: RE: [nycphp-talk] Denying multiple logins to restricted pages


> Well that's why there's a script that resets the expired sessions after a
> given amount of time.  Unfortunately the user has to wait the time or
> contact the admin to reset their profile.  When I did this for a client's
> intranet (it was cf based, but same concept) I had a "reset user" section
> (with a dropdown of users) in the super user account and manager accounts.
>
> Fortunately out of the 75 users who used the system regularly, I only got
> the reset a session request about twice a week or less.  On another
system,
> IP addresses had to be registered, but all those users only logged in from
> their desks, and it was directly tied to the network admin's dhcp list
(that
> was a fun one).
>
> It's very hard to control crashed sessions, unfortunately, which I feel is
a
> serious downfall of browsers as they should allow for application plugs,
> imo.  I'm dying to hear of better solutions though :)
>
> Mark
>
> -----Original Message-----
> From: CHUN-YIU LAM [mailto:chun_lam at hotmail.com]
> Sent: Wednesday, February 26, 2003 11:53 PM
> To: NYPHP Talk
> Subject: Re: [nycphp-talk] Denying multiple logins to restricted pages
>
>
> what happens when something wrong with a session, how do he/she login in
> again?
>
>
>
>
>
>
> ----Original Message Follows----
> From: "Ophir Prusak" <ophir at prusak.com>
> Reply-To: talk at nyphp.org
> To: NYPHP Talk <talk at nyphp.org>
> Subject: [nycphp-talk] Denying multiple logins to restricted pages
> Date: Wed, 26 Feb 2003 13:24:25 -0500
> Received: from parsec.nyphp.org ([66.250.131.26]) by
> mc10-f6.bay6.hotmail.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 26
Feb
> 2003 10:24:55 -0800
> Received: from nyphp.org (parsec.nyphp.org [66.250.131.26])by
> parsec.nyphp.org (8.12.6/8.12.6) with ESMTP id h1QIOPEF082196for
> <chun_lam at hotmail.com>; Wed, 26 Feb 2003 13:24:52 -0500
(EST)(envelope-from
> null at nyphp.org)
> X-Message-Info: dHZMQeBBv44lPE7o4B5bAg==
> Message-Id: <200302261824.h1QIOPEF082196 at parsec.nyphp.org>
> X-Paralist-Archived:
<http://nyphp.org/list/paralist_archive.php?L_mid=3215>
> X-List-Software: Paralist 0.6
> List-ID: <nyphptalk.nyphp.org>
> List-Owner: <mailto:listmaster at nyphp.org>
> List-Archive: <http://nyphp.org/list/paralist_archive.php?L_lid=2>
> List-Subscribe: <http://nyphp.org/list/>
> List-Unsubscribe: <http://nyphp.org/list/>
> Organization: New York PHP
> X-Mailer: Paramail 0.5
> Return-Path: null at nyphp.org
> X-OriginalArrivalTime: 26 Feb 2003 18:24:55.0907 (UTC)
> FILETIME=[5CBDDB30:01C2DDC4]
>
> Hi All,
>
> I'm creating a site that requires people to register and login for access
to
> certain pages. I want to stop users from giving out their
username/password
> to other people by denying access to more than one person using the same
> username at the same time.
>
> I have a few ideas in my head, but would really like to hear from others
> that may have already tackled this problem and what solution they came up
> with.
>
> Also, I'm still debating what to do when I find out that indeed two (or
> more) people are trying to use the same username.
> Do I deny the latest attempt ?
> Do I accept the latest attempt and then reject requests from all other
> people using the same username ? etc.
>
> Ophir
>
>
>
>
>
>
>
>
>
> _________________________________________________________________
> The new MSN 8: smart spam protection and 2 months FREE*
> http://join.msn.com/?page=features/junkmail
>
>
>
>
>
>
>
>
>
>
>
>
>
> --- Unsubscribe at http://nyphp.org/list/ ---
>
>
>
>