PHP, Zend Framework and Other Crazy Stuff
Archive for May 2, 2006
Patching holes
May 2nd
I finally got around to patching several enviromental variable vulnerabilities in Partholan. These were already known about but on the long finger since early versions were changing so much. I have added a small class with static methods for cleaning up such variables – the contents of $_SERVER to be precise which should remove any vulnerabilities where such variables are utilised. For example, since $_SERVER['PHP_SELF'] can be easily overwritten on many Apache installations (via a mod_rewrite style method of appending variables to a URI) we now use:
$phpself = basename(__FILE__);
$_SERVER[‘PHP_SELF’] = substr($_SERVER[‘PHP_SELF’], 0, strpos($_SERVER[‘PHP_SELF’], $phpself)) . $phpself;
$_SERVER[‘PHP_SELF’] = substr($_SERVER[‘PHP_SELF’], 0, strpos($_SERVER[‘PHP_SELF’], $phpself)) . $phpself;
This splits off any unwanted tag along variables that may have been injected into the variable.
Also cleaning up several others, validating IPs (properly – see the ip2long() function), etc. We’re gradually but surely working up the security ladder. There is definitely several more areas needing attention – the goal is to complete all security measures prior to a fully publicised release of QSE or Partholan.
DataObjects, and MySQL setups
May 2nd
I’ve gradually been cleaning up draft 1 of my PHP DataObjects tutorial. At the end of the writing process I have quite a bit of information packed in…hopefully in a legible easy to follow fashion. Don’t quote me on that, I had to be concise where it made sense but I think it’s not too bad. 
As well as the core PHP DataObjects focus I allowed several sections to meander into related areas – namely Code Generation, a little bit on Convenience Methods, and a few other exploratory paragraphs. Once the final edits are made I’ll see if Feyd and the other Devnetwork moderators are happy giving it a public airing, and I’ll post a copy here for reference.
A few interesting tidbits came to light while I was reviewing the original code used in Partholan (the simple framework QS hinges on). I caught a few dormant errors, located some defunct code in primary key handling, and came up with a few potential solutions to multi-row updates and allowing prepared statements. These will eventually hit QS when I return to working on the game – or more specifically Partholans DataObjects classes. This is what happens when you let code simmer for a while before looking at it again; it looks new, you see it in a new light, you catch errors, it improves. It’d be nicer to have a few extra eyes watching my code. But that can’t be helped until the project gets a larger following.
I’m also abandoning (until given sufficient motivation) implementing database results caching in Partholan. At this point I’m already pushing InnoDB in place of MyISAM on the MySQL platform front (QS attempts to enforce it for MySQL4+ already). I really don’t see much sense in trying to outdo something MySQL does so well already (well, since MySQL4). InnoDB performs much betters and I’ll also refer to MySQL4′s intelligent cache. After a little in-house benchmarking and some mind-numbing reviews of slow query logs by myself and a few other colleagues it’s pretty obvious a miserable little 16M cache has a fantastic effect on speeding up MySQL queries. And no, that’s not just on my home PC – real server, serving real users. If any hosts offering MySQL4/5 are not using this feature they should be kidnapped, tortured and shot for the crime. We did note that the SQL queries needed to follow a strict capitalisation convention to take full advantage of the cache – mixing “SELECT *” with “select *”, even if the remaining query was identical, led to split caching based on the capitalisation difference. The query cache uses text matching so it’s something to watch when squeezing a little more goodness out of the system.
Not big news to many folks I know – but the caching idea seems to have lodged itself in the minds of many developers and refuses to budge. There are still new caching articles and tutorials being written which are quite simply out of date with the times – some of their reasoning is laughable. I wonder how many ever read John Lim’s disclaimer on ADOdb’s caching solution… Caching, since the original QS3 plans, has been falling farther and farther down the priority list anyways – consider this an almost-official type decision (Hades reserves the right to kick my ass and up its priority ). Oh, I expect it’ll get added eventually, there are always the few edge cases where it yields a result – but don’t hold any breaths.
Interesting Q I suppose, who is actually using InnoDB as the default storage engine in their apps (for MySQL4)? It requires an extra setting tagged on to CREATE TABLE queries if using MySQL 4.0.x. It’s usually the default on higher versions past 4.1.
