NYCPHP Meetup

[Jim Hendricks]

This sounds just like a method we were going to use before we developed the
"heartbeat" idea.  That was to use a java applet to establish a socket back
to the server to maintain the connection. The idea with the java applet was
that the applet would open a socket to a small socket server running on the
webserver.  It's purpose was to generate the same "heartbeat" we eventually
created with the hidden frame.  Rather than use ASP sessions, the ASP app
would use a table for storing all it's server state.  For security, you had
to have a login to generate a token which was passed back to the client and
added to the login table and used as a session identifier for the state
table.  The heart beat did nothing more than send this token over the
socket.  The only message the server socket understood was open, heartbeat
token, and close.

This method was not acceptable to the customer because they were afraid
there would be users who would not have the ability to run java applets in
their browser.

For the hidden frame "heartbeat", the additional bandwidth was negligible,
it was a simple request generated every 2 minutes and the response was a
minimum html page with a refresh in the header.  The "tick" was annoying,
but the customer was willing to live with it considering the ability it gave
them to not worry about a timeout but also allowed a short ( max 4 minute )
lockout of an improperly logged out session and the ability to ban
concurrent use of a login.

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 12:15 PM
Subject: RE: [nycphp-talk] Denying multiple logins to restricted pages


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