Security is becoming a more and more popular topic among PHP developers, and Joseph Crawford has followed the trend and written up his own look at the way PHP handles session and session information as it relates to the security for both the user and the server admin.

One aspect that I dislike about the internal PHP sessions is that they are stored in files on the hard disk (usually /tmp/) by default. This means anyone with access to the machine has access to read the session data. I prefer to store my session information in the database to add an extra layer of security.

He looks at the pitfalls of using this kind of setup (among them, multiple users being able to use one IP) and a simple method for creating a custom sessions handler to replace PHP's built-in one. His example works with a local database to handle saving and retrieving the session information. And, to make things unique, he generates a "fingerprint key" for each user's information to serve as a unique identifier rather than handling it on the connection.

DevShed is starting up a new series this morning with this new tutorial, part one in the creation of a simple blogging system using PHP and MySQL.

In this three-part tutorial we are going to be creating an open blogging system. We are also going to provide scripts that will make it possible to switch to a closed blogging system. This article, which is the first part, will cover the creation of the login scripts for a closed system.

They start with a definition, the difference between an open blogging system and a closed one (if users have to register or not). They start with the creation of the database to store the users in followed by the PHP code for the simple login page. It uses sessions to keep track of which user is logged in. Of course, where there's a log in, there needs to be a log out and they give the simple code for that. Finally, they include a "forgot your password" script to help users when they can't remember the info they'd signed up with.

In an excerpt from the APress book "Beginning Google Maps Applications with PHP and AJAX: From Novice to Professional", this entry talks about caching the responses from a remote data source into the $_SESSION superglobal during development.

Why spend time setting up a sophisticated cache for the whole responses while you develop your XPath expressions and regexes? Especially if you ultimately will only be caching the results of these actions?

One solution is to simply store the responses in the PHP variable $_SESSION, and then read them out again on the next viewing. To make it even easier, you can just wrap your remote calls in some code that checks it for you.

Their "weapon of choice" is cURL using a wrapper class (specifically this one from Sean Hunter) around it to amke the connection and cache the results. They also include the source of the script as an example.

DevShed has posted the third and final part of their "Serializing Objects in PHP" series today with a focus on integrating all of their previous code with a MySQL database.

Provided that you've already grasped the key concepts about object serialization, in addition to implementing some advanced features, such as the ones I mentioned right at the beginning of this article, in this final installment of the series, I'll show you some examples of how to work with objects and sessions. I'll also show you how to use MySQL tables to keep your objects safe and healthy.

They briefly touch on the code from the previous part, showing how to automatically serialize the objects easily. With that in place, they illustrate how to expand upon it, to combine these objects with sessions to register/store/retrieve them. Finally, they cover taking these same objects and storing them to a database (MySQL), including an example of handling user information.

On CodeSnipers today, there's a new post looking at two aspects of getting Ruby on Rails to cooperate nicely with PHP, specifically in dealing with sessions and the structure/layout of the files that make up the site.

Each of the topics is covered in a paragraph detailing what things look like for either side and a possible solution for cross-communication.