views:

40

answers:

2

I'm playing around with creating a user login system in php.

I have been studying this article (http://www.evolt.org/node/60384) as a way of approaching this.

In the above article, the author uses a combination of $_SESSION and his own custom database table for storing user info.

However...

I have also come across numerous articles that recommend using session_set_save_handler to configure php sessions to use the database natively. (Which I guess is a newer technique.)

I am wondering: If I am planning on setting up an "activeUsers" table in the database for recording session data anyhow, does it make more sense to use session_set_save_handler? (Seems if I'm using the database to store some session info anyhow, I might as well dispense with filesystem sessions.)

Or is there some advantage to leaving php sessions in their default filesystem form, and then x-checking user logins against my custom db table?

Thanks (in advance) for your help.

+1  A: 

Storing session data in a database can be a little tricky to setup at first, but once you have a class or function set up to do this, then you get a few potential advantages over filesystem storage. The question is whether or not those advantages are required for your system. These are, I think, amongst the most common reasons for storing session data in a database:

Security: If using shared hosting, session data may be held in areas of the disk that are accessible by other users of the system. This could constitute a security risk for your application.

Scalability: If your application is handled by more than one server (a server farm, for instance_, you need to ensure that multiple requests from the same client, which may be processed by different servers, each receive the same session data. This is quite easy to do if the session data is in a database.

Performance: Database storage may give a performance increase over filesystem storage, but this is heavily influenced by the server configuration.

DB interaction: Depending on the role of your session data, and how your application uses it, it may be easier to retrieve session data and related information if it is all in a database.

Something else to consider is that you can enhance the session information by storing additional information, such as IP addresses, log on and log off times, and so on. This sort of information can be useful when trying to prevent session hijacking.

So, other than the scalability issue, I think it's all quite subjective. You need to weight up the extra work required to implement database session storage, with the possible benefits.

Mike
Thanks Mike for the response. Looking over those 4 reasons, none of them apply to my case. So I have no concerns with using conventional sessions - *except* - I am planning on creating a db table "activeUsers" anyhow. I am still unclear if it makes more sense to have the sessions use the database natively, if some user 'session' information is going to be going in the database either way.
Travis
@Travis: It doesn't sound as though you *need* to store session data in a database, but your application could end up a little cleaner if you do. You could try the [Pear HTTP_Session2](http://pear.php.net/package/HTTP_Session2) package if you don't want to write your own handler.
Mike
+1  A: 

If you use it you need to make your own garbage collector.

Codler