Exclusive session

[forje]

Hi all,
How to make a session "exclusive"? When one attempts to open a new
session either he's warned and asked to wait or any other openned
session is closed.
The need is to force only one user at the same time.
I'm currently using the database but also looking at a php only solution.
Thanks in advance.
--
Forje

[Gordon Burditt]

>How to make a session "exclusive"? When one attempts to open a new

>session either he's warned and asked to wait or any other openned
session is closed.

If a session is already open, PHP generally just uses that session
and does not try to open another one.

>The need is to force only one user at the same time.

Since there are plenty of ways to leave a session without informing
PHP of that, this is going to be a severe problem. You can time
out sessions but that can be very annoying to your users. Indefinite
lockouts are even worse.

>I'm currently using the database but also looking at a php only solution.

There really isn't a good solution, period, unless allowing a user
a maximum of zero sessions is acceptable.

[forje]

Gordon Burditt a écrit :

>How to make a session "exclusive"? When one attempts to open a new
session either he's warned and asked to wait or any other openned
session is closed.

If a session is already open, PHP generally just uses that session
and does not try to open another one.

It is a particular application: a remote interface to administrate a
system. The idea is to prevent concurrent access to the system. Stop on
one side, start on an other...

>The need is to force only one user at the same time.

Since there are plenty of ways to leave a session without informing
PHP of that, this is going to be a severe problem. You can time
out sessions but that can be very annoying to your users. Indefinite
lockouts are even worse.

In this case, a direct close of any other openned session would not be a
problem.

>I'm currently using the database but also looking at a php only solution.

There really isn't a good solution, period, unless allowing a user
a maximum of zero sessions is acceptable.

PHP does not give a client the direct knowledge of the existence of
other connections. That's why I use the db for the moment.

[Gordon Burditt]

>>How to make a session "exclusive"? When one attempts to open a new

>>session either he's warned and asked to wait or any other openned
session is closed.

If a session is already open, PHP generally just uses that session
and does not try to open another one.

It is a particular application: a remote interface to administrate a
system. The idea is to prevent concurrent access to the system. Stop on
one side, start on an other...

>>The need is to force only one user at the same time.

Since there are plenty of ways to leave a session without informing
PHP of that, this is going to be a severe problem. You can time
out sessions but that can be very annoying to your users. Indefinite
lockouts are even worse.

In this case, a direct close of any other openned session would not be a
problem.

Don't be too sure. You never have browser crashes, modems dropping
carrier, power outages, or net outages, none of which close an open
session? You never get distracted and have to navigate elsewhere?

>>I'm currently using the database but also looking at a php only solution.

There really isn't a good solution, period, unless allowing a user
a maximum of zero sessions is acceptable.

PHP does not give a client the direct knowledge of the existence of
other connections. That's why I use the db for the moment.

Poking around the session save files of other sessions is a
possibility, but direct use of a database is probably more efficient
and less likely to cause trouble with two near-simultaneous login
attempts from different places.

[forje]

Gordon Burditt a écrit :

>>>How to make a session "exclusive"? When one attempts to open a new
session either he's warned and asked to wait or any other openned
session is closed.
If a session is already open, PHP generally just uses that session
and does not try to open another one.

It is a particular application: a remote interface to administrate a
system. The idea is to prevent concurrent access to the system. Stop on
one side, start on an other...

>>>The need is to force only one user at the same time.
Since there are plenty of ways to leave a session without informing
PHP of that, this is going to be a severe problem. You can time
out sessions but that can be very annoying to your users. Indefinite
lockouts are even worse.

In this case, a direct close of any other openned session would not be a
problem.

Don't be too sure. You never have browser crashes, modems dropping
carrier, power outages, or net outages, none of which close an open
session? You never get distracted and have to navigate elsewhere?

If a session is still open because another user leaved without closing,
a new connection would close it anyway or at least prompt the new user
for 'kill current admin session y/n?'
To do that, I need to check a flag in the database for any action in the
current session (to see if a new connection is active and close brutally
the current session if needed. I would like to avoid this check in db.

[Peter Fox]

>To do that, I need to check a flag in the database for any action in the

>current session (to see if a new connection is active and close brutally
the current session if needed. I would like to avoid this check in db.

(1) You need to use something that all 'connections' can see and share.
Sessions don't fill this bill.

(2) Since you will (won't you? - I would!) be recording access to the
admin system, you'll be keeping database records anyway.

(3) Unless a user explicitly logs out (or completes some final action)
your system can't tell when a session has ended.

My answer would be to provide
* a log-out function (It will be forgotten but use a bit of psychology
to provide a useful information screen or 'here's your new look' as a
result to encourage its use.)
* a /warning/ that another admin session appears to be in progress
(including who is the other user) ...
* ...with a simple override.
* possibly the logic for 'is there another admin session in progress'
would look at recent activity in the audit trail and conclude that if
nothing has happened in the last 15 minutes then the new user can be
given control anyway.


--
PETER FOX Not the same since the e-commerce business came to a .
pe******@eminent.demon.co.uk.not.this.bit.no.html
2 Tees Close, Witham, Essex.
Gravity beer in Essex <http://www.eminent.demon.co.uk>

[forje]

Peter Fox a écrit :

>To do that, I need to check a flag in the database for any action in the
current session (to see if a new connection is active and close brutally
the current session if needed. I would like to avoid this check in db.

(1) You need to use something that all 'connections' can see and share.
Sessions don't fill this bill.

Yes.

>
(2) Since you will (won't you? - I would!) be recording access to the
admin system, you'll be keeping database records anyway.

I will.

(3) Unless a user explicitly logs out (or completes some final action)
your system can't tell when a session has ended.

Yes.

My answer would be to provide
* a log-out function (It will be forgotten but use a bit of psychology
to provide a useful information screen or 'here's your new look' as a
result to encourage its use.)
* a /warning/ that another admin session appears to be in progress
(including who is the other user) ...
* ...with a simple override.
* possibly the logic for 'is there another admin session in progress'
would look at recent activity in the audit trail and conclude that if
nothing has happened in the last 15 minutes then the new user can be
given control anyway.

I can't avoid to always check (in all scripts) if a new user is here and
stop if yes.
Thank you for the analysis.
--
Forje

[forje]

Gordon Burditt a écrit :

Poking around the session save files of other sessions is a
possibility, but direct use of a database is probably more efficient
and less likely to cause trouble with two near-simultaneous login
attempts from different places.

It's hard to have access to all session files from a particular session.
How would you do that?

[Jerry Stuckle]

forje wrote:

Gordon Burditt a écrit :

>>Poking around the session save files of other sessions is a
possibility, but direct use of a database is probably more efficient
and less likely to cause trouble with two near-simultaneous login
attempts from different places.

It's hard to have access to all session files from a particular session.
How would you do that?

It's hard to do from the default session handler. However, you could
install a custom session handler, i.e. database driven, to handle the
sessions. Then you have easy access to all sessions.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[C.]

1) PHP sesions aren't really intended to be left open indefinitely.
Apart from anything else its something of a security risk. The fact
that PHP will create a session when the one asked for does not exist
is, in itself a major security problem (see the links to session
fixation from the PHP site).

If exclusivity is the objective then this should be implemented using a
server-side mutex.

forje wrote:

Gordon Burditt a écrit :

Poking around the session save files of other sessions is a
possibility, but direct use of a database is probably more efficient
and less likely to cause trouble with two near-simultaneous login
attempts from different places.

It's hard to have access to all session files from a particular session.
How would you do that?

Write your own session handling functions which:

1) create a mutex and link the session to it if the session relates to
an exclusive process, and the mutex is not currently in use, or the
mutex is associated with an expired session.
2) when removing a session, unlink and close any corresponding mutex.

Of course (1) above assumes that any session has (at least) limited
visibility of other sessions - which in itself is a security problem.
However it would be really quite difficult to build a session handler
where this was not the case, and every one I've seen does not address
this.

HTH

C.