hey Russell!

following the outline you gave me, I used this day to make such a
functionnality.

BTW, I already knew that users log into the database, not the tables,
but I thougt that it would be the correct wording (hey, Geoff? :-) )

the only drawback I found was that the users *could* use the same
username/password, and defeat the system. to defend myself against
this comportment, I also log the ip adress.

So, I use the username + IP pair to authorize the login/access to the
"zone". if the pair is different, that "connection" becomes a new
user.

The login and logout are done at the client. At the login, I first
delete all connections older than 15 minutes, in case a client
aborted. I then authorize/refuse access to the zone. A "keepalive"
is sent every 15 minutes once the zone is entered.

Just in case, I log the connections data using jumblestring, except
the keepalive timestamp. As stated in the docs, jumble is not the
best encrypting algo, but I think it is good enough to keep even power
users at bay. the customers rareley have real hackers in house,
orelse, they would be doing the programming...

I realize, after reading Geoff's comment about terminal servers and
linux, that this is not the perfect solution. A problem could also
arise if the clients are in various timezones. This is however the
best thing I could come up with on a relative short notice. Now that
I have something working (ie:good enough for now), it could be
interesting to find a way to limit concurrent users (in a zone or at
large) in a more complete and extended way.

anyway, that was "my story of the day" (tm)

Spou

--- In IBObjects@y..., "staff@b..." <russell@b...> wrote:
>
> ----- Original Message -----
> From: Geoff Worboys <geoff@t...>
> To: <IBObjects@y...>
> Sent: Thursday, July 05, 2001 1:39 PM
> Subject: Re: [IBO] limiting concurrent users
>
>
> > > As I am about to deliver a nice little software running
> > > over interbase, I am now in the situation where I have
> > > to limit the number of concurrent users logged into some
> > > tables (but not all the tables).
> >
> > Users do not "logon" to individual tables - databases yes, but not
> > tables.
> >
> > I think the best you can hope to achieve is to build something
into
> > your client application that logs access details when a form is
> > openned, and clears when a form is closed. Of course this will
mean
> > problems when the application aborts or the connection fails for
some
> > reason ..[...]
>
> Here is a simple method I use:
>
> Suppose your applications know when a user is in the place where
they need
> to register as a concurrent user.
>
> When in that zone your timer runs an update procedure every 5
minutes, say,
> saying the users is still logged in to the zone.
>
> When the user exits from the zone log them out by running a
procedure on the
> server.
>
> When a user first logs into the zone delete any logged in users
whose update
> is 6 or more minutes old, and log the user into the zone. Count the
current
> number of zone users and do your prevent access logic.
>
> The times need to be tuned to your application and your
restrictions.
>
> Regards
>
> Russell