RE: [PHP] custom session management and authentication
| From: | Jaime Bozza | Date: | Thu, 24 Oct 2002 15:38:50 +0000 |
| Subject: | RE: [PHP] custom session management and authentication | ||
| References: | 1 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-121294@lists.php.net to get a copy of this message | ||
> 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.)
> 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'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?
Jaime Bozza