Well I’m tired of reinventing the wheel. Since it’s fifth installment, PHP provides an API easing access to all types of databases called PDO functions. All the features you need are in there, coded in C by NASA engineers and is likely better than anything I could come up with.

You really should read up on the PDO if you currently maintain a custom database access object — or none at all. Also, as the documentation points out, this is not a full-blown database abstraction layer (to run MySQL, Oracle or others transparently) it’s a data-access abstraction layer (so make sure your queries are properly formed for the database you want to use).

Learning what not to do

On TMT, I used to handle sessions manually by storing the encrypted value of the user’s id in a cookie. That’s is highly unrecommended for security reasons as its fairly easy to hack your way around using an id that isn’t yours (and which might be the administrator’s!).

I experimented by storing so-called ‘unique’ values I generated and stored in MySQL to have better validation when decrypting the cookie, but since you can spoof most $_SERVER values (which provides the user’s IP), it really wasn’t good enough.

Hardcore PHP-ing

You can override the whole session object using PHP’s session_set_save_handler() function. Basically, you re-program what the object does when it reads and writes session values or when it destroys itself.

Instead of writing the session values to a file on the server like the default behavior is set to do, you can redirect the data handling to an insert or update query in your favorite database.

Advantages

The most obvious advantage is that you can keep the sessions alive as long as your server is live, more or less. You can also change the condition of how session expiration are done. For instance, through a simple MySQL query, TMT sessions can be kept for one week before being destroyed if no activity is logged.

I’ve read it’s safer to store session values that way too, as a possible hacker would need the database’s password to access it. While I’m not sure how harder this method actually makes it for hackers in reality, I really feel safer to use PHP’s native object rather than a shaky class I would have written.

Fully using PHP’s native session object allows more flexibility as you are very close to Apache. You can therefore validate with confidence (not blind confidence though) that the user is indeed human and not a spam bot, save the user’s preferred language or do whatever else your website offers as possible features without fear. In my previous horrible system, it wasn’t even a possibility.

Examples

Apart from stalker at ruun dot de’s very good comment on PHP.net’s documentation page, I found Tony Marston’s version of the object. The latter is harder to grasp as he uses his own object-oriented system to get database data — that’s good practice, but a bit harder to learn from. You can also see TMT’s class in our SVN repository.

The important thing is just to understand what you’re trying to do rather than copy pasting each of our codes. TMT’s only started working once I grasped the concept.

However, all the tables and database structure I had built stayed with Abnormis. Hopefully my old server will come back online and I will be able to get some of the file content back, but I am really just interested in how I had built my tables — which I don’t think I’ll be able to access. I don’t even remember most lengths and data types of the columns. Even my PHP source code can’t give me much hints at the moment.

At least this morning I was able to reconnect the user table. This means future posters and tankers can already join the Tank… and do nothing afterwards. Hopefully I’ll have the news working by early afternoon.

The moral of the story is that a backup, when you are developing, is always too old.

And damn do I need to fix the transparent issues with IE 6 as soon as possible!