On Thu, 14 Oct 2004 16:21:45 -0400, Burns, John D
<[EMAIL PROTECTED]> wrote:
> I think the biggest decision that the person who asked will have to make
> is the business logic for when a session that is currently logged in is
> no longer logged in.  For instance:
>
> If User A logs in at 10AM and is given a 60 minute session and is
> somehow flagged as logged in (either in DB or app structure).  The user
> does 1 quick thing on the site and then closes the browser at 10:05AM.
> This user gets up and moves to another computer and attempts to log into
> the site.  He won't be allowed until 11AM if you do it this way.  Since
> there's no real-time checking if the client is still there (unless you
> use flash remoting or a "ping" type iframe - which I would say is
> overkill) then you can't really handle this type of situation without
> sacrificing, that once someone logs in, no one can log in with that
> account until the session expires (even the person who started the
> session...unless they're on the same machine and have a cookie or
> something).
>

One place that I worked, restricting concurrent logins had to
abandonded due to this very problem. It was especially hard to do
develop while at the same time restricting concurrent logins. The API
that they had built for security had a switch in it that allowed a
developer to turn on or off concurrent logins depending on a value in
the web descriptor file (J2EE). However, even with this, we had to
turn the feature off for production web apps.

Too many times, users would login to the apps for a few minutes, check
something and forget to logoff. Then they could never figure out why
they could not log back in a few minutes later. We could never
convince users that they had to logout every single time. They would
just close the browser instead of logging out.

--
chris johnston

www.fuzzylizard.com

"For millions of years, mankind lived just like the animals and
something happened which unleashed the power of our imagination, we
learned to talk."
Pink Floyd
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]

Reply via email to