Re: [PHP-DEV] Session management module - thoughts From: Ariel (ars <email protected>)
Date: 05/28/99

On Fri, 28 May 1999, Rasmus Lerdorf wrote:

> > Hmm, that's not true; Your browser opens many HTTP connections to the
> > same web server with the same cookie - it may blow up.
>
> Yeah, when I was thinking about it I figured that the other connections
> would be for inline images where presumably no session stuff was needed.
> I forgot about the frames case.

Also plenty of times people use two browsers together to browse sites, or
two people use the same login.

As I see it, there are two issues in session management.

Identifying the user, and storing persistent data for that user.

For the first, you can use an auto-generated identifier, or one where the
programmer picks it (for example if a user logs in). If the programmer
picks it, it's up to him what to do and how to store it. If it's auto
generated, then 90% of the time, this is a cookie, the rest it's a URL
variable.

The second part is getting data based on some sort of identifier, this
should be flexible enough to handle either a string on an int as the key.
It can either take the auto generated parameter, or one that the
programmer specified.

There is more then one method for storing this data (the data store). This
can be an SQL database, and DB file, a text file, or on windows the
registry. Or it can be purely memory.

The challenge here is concurrent access. It's not enough to just lock the
variable when changing it to avoid corruption. (The mechanism used
depends on how the data is stored.)

Suppose you have two pages that do:

$a = $session + 1
;slow code here
$session = $a

I'm sure you can see the race condition here, if two pages both run this
code - it can be far worse if there is a lot of slow code in between.

In order to successfully do this, it's necessary to have some sort of
user set advisory lock, where the programmer can lock critical sections of
code. If a second process encounters an already locked section it waits
for the first to end.

Locks are automatically closed at the end of the process if the user
forgot. A timeout with a user tappable error is probably a good idea
here.

For persistent data storage, there is usually three different kinds, all
of which can be stored in the same way.

The first is global php wide variables. This can be used for seeding a
random number generator, and for any sort of init code that needs to run
only once.

The second is application variables, these allow each application
(collection php scripts the programmer has defined as working together) to
store data together. This is simply a generalization of the above, the key
could be the application name, rather then global.

The third is user variables that only apply to the specific user (browser
usually).

All three variables can either persist between restarts of php, or only
until apache is killed (or for cgi only last each session).

Finally it is necessary to be able to specify a timeout, which once
reached deletes the variable. You don't want old data littering the data
store. This timeout is reset each time the variable is accessed rather
then each time it's written.

Anyway this is what is involved in session management. You might want to
rethink getting rid of phplib - probably you should merge it into php. And
you will always need some setup work, depending on the data store you pick
can be a lot or a little.

        -Ariel 

--
PHP Development Mailing List   http://www.php.net/
To unsubscribe send an empty message to php-dev-unsubscribe <email protected>
For help: php-dev-help <email protected>