Re: Session management module - thoughts

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@lists.php.net For help: php-dev-help@lists.php.net