RE: [PHP] custom session management and authentication
| From: | Brad Pauly | 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
>
>
>