RE: [PHP] custom session management and authentication

From: Date: Thu, 24 Oct 2002 15:57:11 +0000
Subject: RE: [PHP] custom session management and authentication
References: 1  Groups: php.general 
Request: Send a blank email to php-general+get-121302@lists.php.net to get a copy of this message
On Thu, 2002-10-24 at 09:38, Jaime Bozza wrote: > > I use an associative array to hold session data > > ($session['foo']). New variables are easily introduced to a > > session with array manipulation. The array is serialized and > > stored in a database when the session needs to be saved along > > with some other data. It is then pulled from the db when > > needed. The key is a unique ID that I generate when a session > > is created. The session can be killed by deleting it from the > > database, or removing the authentication cookie. > > Isn't this pretty much exactly the same as PHP4's session support? PHP > creates a session id (or you can create one yourself), the data from > $_SESSION[] is serialized and stored in files or a database or whatever > session_user_handler you specify. Variables can be added or removed as > needed. Sessions can be killed by deleting it from the database or > removing the cookie. All the functions are available in PHP already, > with the exception of using more enhanced session handlers (like using a > database instead of files, but even that's readily available with using > a user-defined session handler. I think there's even a PostgreSQL > session handler that was developed by one of the PHP developers.) It certainly could be. I came to PHP from ColdFusion where I started doing this because I wanted more control over sessions and I think this method is more secure. It worked well, so I did it with PHP too. I will need to read up some more, but the big benefit is in the way client authentication works. The session id is not stored on the client. It is retrieved from the authentication token. This makes it more difficult to guess a session id. > > I rely on cookies to hold a client authentication token. This > > is compared to a token generated on the server for > > authentication. Very similar to the method discussed in this article: > > http://www.usenix.org/events/sec01/fu/fu_html/index.html > > PHP Sessions support URL and cookies. PHP 4.3 will have the ability to > turn off URL-based session id's (though you can fairly easily force > cookie-based session id's through an include file that sets up session > id's yourself before calling session_start()) > > Generating the token is important, to make sure they're all unique, but > the security of the token is lost by the fact that the client side needs > to know what that token is to send it off. I don't quite understand what you mean about the security being lost because the client side needs to know about it. The client knowing is implicit to maintaining state. However, like I said above, the session id is not stored on the client. Did I misunderstand you? > I'm not sure what you're doing differently from the built-in session > support, or am I getting confused and you *are* using the built-in > session support? Nope, I am not using the built-in session support. =) It sounds like it would be easy to do the same thing on top of the built-in support. I do like knowing exactly what is happening, but maybe I will look into trying it that way. Brad > > Jaime Bozza > > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > >

« previous php.general (#121302) next »