Category: Uncategorized

In the current issue of php | architect, there’s an article about “enterprise ready” session management. While it provides a nice look about how to structure your application (besides the capital mistake of endorsing a multiple-entry application structure – but I’ll save that for another post) and about some design-patterns, I have one big objection to the article: It’s basically saying that the $_SESSION-things in PHP are not enterprise-ready. The article names three reasons:

1. It is not OOP enough
2. The Session-ID is guessable
3. The storage location for the session-data does not work with load balancers

The article then goes fruther and writes a complete replacement for PHP’s session API

Now. Le’ts have a look those points:

Point 3 is valid. If you load balancer cannot guarantee that each subsequent request from a user goes to the same server, /tmp is not a good place to store session data. What the article does not tell you is that most load balancers actually do make that guarantee. Reading the session-data from a file, unserializing it, using it, serializing it, storing it to a file probably is faster than doing the same thing with a database. Maybe you should do some testing and then deceide – at least when you have the real enterprise-grade-load balancers at your disposal.

Point 2 is also somewhat true, but the workaround provided by the article is not any better than what PHP already does. I especially dislike taking a hash of the first two octets of the IP-adress for protection against session spoofing. Hey. 2 octets of IP-range are not checked. This are 65536 addresses. Say I want to spoof sessions on your site, instead of those 4 billions of users I only have 65 thousand to try it with, but let’s say even only 1% of the users in said range do some online financial transactions on your site, it’s worth it for me. I just make an accaount at a particular ISP and try out my range.

It’s unfair to say PHP’s session ID generation is weak because it uses the systems time (amongst other things) and then create a replacement algortihm using the systems time (amongst other things).

The idea with the second ID is somewhat valid, but does not protect at all against network-based attacks (listening on the network and sending a valid request)

My biggest concern – the one that actually made me write this – is point 1. Tell me: What’s better at

 HTTPRequest::getSession()->getValue('gnegg');

than

 $_SESSION['gnegg'];

As I see it, the first version has three distinct disadvantages:

• Depending on the state of PHP’s optimizer, this involves two function calls (in PHP userland code – and maybe countless others in the backend) per variable you query (and with the proposed implementation one additional database query(!)). Function calls are expensive. This is inperformant. Not with two to three queries but with maybe 100 or 1000 per second
• The second method is the one documented and endorsed by PHP. Any coder you will find will know what it means, and how to work with it. Whenever you hire a new coder, he immediately will understand your session management code and will be able to concentrate on the business logic. The first method does not have this advantage. It’s just another hurdle for the coder to take before being able to be productive. A needless hurdle
• It’s more code. More to type. More work to do. Thus inefficient for your programmers.

Saying the first one is better because it’s more OOP is like saying “I am more 31337 than you because I’m using Windows”, or “rogues in world of warcraft are more 31337 than warriors” or … take your pick (a phrase involving vi and emacs springs to mind).

So. From the three points the author of the article had to present, only one, maybe two are valid. Does this justify dumping the whole session management functionality in PHP? No it does not. Dumping ready-to-use funcationality is always bad. Especially if the funtionality you want to dump is extendable (and thus fixable for your purpose).

The PHP session management can be customized! Just have a look at the manual. There is session.save_handler, session.serialize_handler. There’s even session.entropy_file

So after all, another of those people trying to be god-like by writing about the enterprise without really knowing what it means. The java world is full of such individuals. And now PHP is getting them too. The price for being known? Maybe.