NYCPHP Meetup

[Mark Armendariz]

I had actually done the same thing on the fore-mentioned intranet.  The
hidden refresh is Definitely an effective way to maintain a short session,
although it does give a slight hit to bandwidth, and also the users with the
nice speakers hated ie's "clicking" on every refresh.

But in reading this I also remembered another solution that came to mind,
which I had never actually tried, but thought might work well.  On one of my
side projects, I had created a socket based chat.  The backend is php (I
started it with perl, but i'm more comfortable with php).  It basically runs
in the bg on my server waiting for socket connections to a specific port.
The chat client is using flashmx' socket goodies (using xml_sockets for
those keeping score).

Now, I know this sounds a bit in depth for user tracking, but the best part
of it is, no matter how flash closes, be it refresh, browser crash, etc, the
socket connection always closes.  So if the connection doesn't reopen within
say 30 - 60 seconds, it can be expected that the user logged off or is
having connection issues and that their session can be closed off.

If you're interested in trying it, I've seen a few socket server scripts out
there.  I have a class I written, but I still have some debugging to do on
it.
Here's some info on it:
http://www.devshed.com/Client_Side/Flash/XMLSockets/page1.html

I guess I may give it a shot eventually.. Once I find a decent gig to keep
my landlord happy.

Mark

-----Original Message-----
From: Jim Hendricks [mailto:jim at bizcomputinginc.com] 
Sent: Thursday, February 27, 2003 8:09 AM
To: NYPHP Talk
Subject: Re: [nycphp-talk] Denying multiple logins to restricted pages


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/ ---