Propel

Pros – First, let’s be clear I’m not talking about the pros of using an ORM. I’m talking about the good things that this ORM implementation brings to the table. Those are:

• Hydration Speed – You can argue you should never retrieve hydrated PHP objects from query if you don’t plan on taking some sort of save or delete action on it. Yes, that’s true from a performance standpoint, however, if you are building a site where performance simply isn’t a concern then you’ll be pleased to know Propel can hydrate a set of objects quickly enough to be used in building a view (i.e. a data grid of some sort).
• Classic Getters/Setters – You get these methods stubbed out in the base classes that Propel generates and you can override them easily. I should note Doctrine can do similar sorts of things but not in a conventional way.
• Support – The Propel mailing lists and IRC channel on freenode are pretty active, thought, not near as active as Doctrine’s.

Cons

• Dependency hell – Propel has improved this but it’s still not perfect. Back in the early days, before PDO, you needed Propel’s generator, Phing and Creole. Now you just need the generator and Phing. Phing is very much like Java’s Ant build tool. While I understand and get why they use Phing, it adds a layer of complexity that makes it a barrier to new users. Propel’s generator isn’t as bad as it is just a set of Phing targets to do Propel’s bidding. If you come from .NET or Java using Phing won’t be a big deal but if you aren’t familiar with Ant or nAnt then Phing will come with a learning curve.
• Criteria – Propel’s way to help ensure portable queries are built is via their Criteria object. While I get the need for it, not having a explicit way to run native SQL short of getting a PDO connection and doing all the work that way is a short coming. In fact, I despise Criteria so much I never use it, mainly because it doesn’t take too much work to hit a situation that Criteria either can’t handle well or make the code so complicated it’s not worth it.
• No 5.3 namespace support – Let’s face it, we are all tired of Really_Long_Class_Names ala PEAR, Zend Framework, et. al.
• Community – This is probably hard to blame on any one person but for a long time no work was done on Propel. There was a change in project leads which took a long time and the development efforts took a while to get going. I’m happy to say the team is active again, but a lot of ground was lost during the downtime.

Doctrine

Pros

• No other dependencies. Doing builds is easy as creating a simple PHP command line file and running it. No Phing, no other external property files.
• Magic finders – I love this. Say you have a user table with a user_name field that has a unique index on it. Retrieving this is as simple as

  Doctrine::getTable('User')->findOneByUserName('janedoe');

  . Propel would require a few more lines setting up a Criteria object and running it.

• Named Queries – This is something I pitched to the Propel development team quite a long time ago that always got a luke warm reception from the community. I ended up implementing my own named query implementation which worked well enough that I never used Criteria. With Doctrine you just get it out of the box:

  $this->addNamedQuery(
      'someQueryName',
      \Doctrine_Query::create()
          ->select('*')
          ->from('User u')
          ->where(user_name = ? AND 'password = ?')
  );
  

  Now I’m not totally in love with that syntax, it’s not much better than Criteria, honestly, however I go through that pain once and then I can just say:

  $user = \Doctrine::getTable('User')->find('someQueryName', array('janedoe',SHA1($password)));
  

  It’s also worth noting you can also use named queries to issue raw SQL, though, it will only return the raw recordset. Some of you are probably asking WTF? Named Queries? Read up on them, decide for yourself if they are for you…all I can say is after having used an implementation for years I’m sold on it (maybe that can be a future blog post).

• Documentation – Their documentation is top-notch. Only improvement that is needed is comment support to the manuals.
• Community – Let’s face it. Doctrine has gained some traction and all you need to do is follow the mailing lists, IRC and other community resources to see they simply get it. Their partnership with Zend Framework is a shining example of good strides in this area.

Cons

• Hydration Override – This one had me scratching my head the first time I noticed it. By default, if you fetch an object by the same primary key twice you don’t get two different copies, you get a pointer to the most recent version. On the surface that makes sense but there are a number of reasons I don’t like this as the default setting. Luckily you can turn this off through a configuration setting when you initialize Doctrine.
• Hydration Speed – This is my biggest complaints with Doctrine. If you run a query that pulls a parent/child relationship (i.e. a customer and their orders) this take a lot of time with Doctrine’s hydration method. The complexity is the circular references you can get. I don’t know why Propel handles this so much better but the impact is you can’t use Doctrine’s hydrated objects in you views. The way around this, I’ll call the Doctrine Way, is to have them hydrated as arrays. You still get the parent’s children, you just aren’t working with a native PHP object. When you think about it, it make sense, though I still prefer having a choice. The performance hit you take, even on simple queries, makes the array hydration mandatory if you are pulling more than one or two records from the database.
• No 5.3 namespace support – It too doesn’t support namespaces yet.

This isn’t meant to be a comprehensive review of either system, rather, a punchlist of noteable things. I don’t feel this blog post is near comprehensive enough to base your decision on, rather, it can be used in addition to your findings. I’d love to hear the other pros and cons from either camps.

I owe quite a bit to Geeklog…after installing Linux and PHP for the first time over 12 years ago I ran across Geeklog, learned a thing or two about open source development and started Iowa Outdoors (which I’ve since sold). Not long after that I was fortunate enough to serve as the project lead for Geeklog before handing it off to the current lead, Dirk Haun. Back then, there weren’t many viable options in the now overcrowded PHP CMS market. Sadly, I’ve watched Geeklog’s popularity slowly decline to its current state. That said, I have a few constructive things to say to the Geeklog community and the PHP community at large.

First to the Geeklog community. You’ve run into rough times. WordPress, Joomla, Drupal and company really are the champions in this space. Without doing more digging than I care to, I know Geeklog is far behind in any of the hard metrics that really matter (code commits, # of active developers, etc). Just a hint of proof is had by comparing Geeklog’s Ohloh stats with this, this and this. Then there those things you can’t quite quantify, the passion of the community and the level of innovation happening. Right now I feel the Geeklog community is pretty stagnant. Some of this is likely to be blamed on the fork of Geeklog (whose Ohloh stats don’t speak well either). Fact is if you combine both glFusion and Geeklog’s numbers together it still paints a pretty bad picture. You could argue they don’t need to aspire to be like WordPress, Joomla and Drupal which is fine but what I think has gotten lost in all of this nobody has consciously said if that’s the game they want to play and, if not, what differentiates Geeklog from the rest? In the meantime, the set of features added over the past year or two suggest, in fact, they are playing catch-up to some of the features found in those other systems. That’s not bad, but my point is Geeklog seems to lack a tangible goal. I guess that is part of the nature of open source…the perpetual, organic, itching of scratches but I still feel open source projects need to have long term visions far beyond the next commit, next point release and even next major release. With that said here’s some suggestions for Geeklog’s community in no particular order:

• Change your name – I attempted to address this with AptitudeCMS and failed but something has to be done. I’m not sure if there is a precedent for a name change in a well established open source project but it has to happen for Geeklog. To me it is branding 101. For anybody outside of a blogger or hobbyist, it’s hard to take the Geeklog brand seriously. Pointy haired managers scoff at such a name (I’ve seen it). Sure you risk confusing or alienating people but I feel Geeklog, as a brand, is hard to sell. That said, even without a name change the remaining points are crucial.
• Change your image – The Geeklog homepage screams mid-1990′s era design. It’s the first impression we give users. Even if you don’t want to compete directly with the bigger kids on the block, you can’t argue that Joomla, WordPress and even the Geeklog fork looks better. It’s the first impression a user gets. I think improving the Geeklog homepage will lead to more interest. Once captivated, I have now doubt the codebase speaks for itself but, for now, the Geeklog homepage is forgettable for new users.
• Get social – Geeklog is no where to be found on Twitter, Facebook, etc. The missed opportunities here are, frankly, staggering. The PHP community (as well as Drupal, Joomla, etc) all have a strong presence in these areas and I have no doubt the Geeklog community could benefit by joining the conversation.
• Blog – Let’s face it, there isn’t much in the way of active Geeklog developers. The ones there really need to blog about what’s going on behind the scenes. What are you working on? What’s a challenge you are facing? Any good commits lately? This in part gets back to the goal setting discussion but it is more todo with giving the community a glimpse of what is going on.
• Find a partner – Ok, this is probably one of the more controversial points and one that is often dodged in open source discussions but behind nearly all successful open source projects is an organization. Sometimes it is not-for-profits but many times it is a private company or two. Right now there isn’t a single Geeklog developer paid to work full time or even half-time on the core of the system. Geeklog’s current codebase, in my opinion, has to be worth that investment. I think part of the problem here has to do with the name, image and branding issues I brought up. That said, I know of a lot of organizations making selfish use of Geeklog without giving anything back. No bugs, no code, no testing, no translations nada. Zilch. Now before the hardcore OSS supporters flame me, I’m not suggesting the project be effectively run by a company or an organization, rather, there should be enough of a community still where they can contribute developer hours to the project. I believe strongly the project itself needs to remain organic able to change with the needs of those who lead…but that some investment by industry is needed. Who will stand up?

Now to the PHP community at large. As I look at AptitudeCMS, I see a body of work that started before there were any other PHP frameworks around. I started with an MVC implementation. I incorporated a simple template engine. Later added an ORM. Much of this happened over many employers and well before anybody uttered Zend Framework for the first time. AptitudeCMS as a project is a failure in large part because it was never really released as a “formal” project until well after current PHP framework space became cluttered. Fine, it is what it is. However, to see this stuff rot and be used only when I have a new project come up seems silly. I’m pleading, for my own sanity, don’t let this code go to waste. Feel free to dissect it, borrow anything you find useful and laugh at any bad code you dig up. Some areas of focus:

• MVCnPHP – It’s a viable alternative to Zend Framework’s MVC implementation. It’s small, configureless and doesn’t present file contention issues common with ZF controllers. I’m sure a Zender can point out ways around this but most ZF projects I’ve seen have all the logic in the controller which seems really wrong to me and is a bit painful when you have multiple developers working in the same controller. Sure SVN, etc can handle the merge but you end up with a lot of merges. MVCnPHP is much more atomic, view logic goes in a simple, small view class. Command logic goes in a similar command class. The controller is only responsible for routing requests between views and commands. An upside to this is MVCnPHP also has basic support for tainted variables. For the unaware, it’s a simple feature that notifies developers with exceptions when an unsanitized GET or POST variable is used.
• Filtering – I built a filter class on top of Zend Framework that can easily be added to MVCnPHP views and commands. Without much work it could also be incorporated into Zend Framework MVC implementations. Look first here then see the “cool code” in the Filter class which is nothing more than a class that passes calls thru to Zend’s library and then the abstract view that uses it. I doubt the code will tickle you as is but I think conceptually it has merit for someone out there.
• ORM->Form and Form->ORM – Because we use Propel we were able to dream up a way where we could hand a view an object and have it pre-fill from that object without us having to explicitly set the form field values. Similarly, in our commands we found a handy way of creating the same ORM objects from the submitted form without having to explicitly map and set the ORM object’s values. This was a huge time saver. I think with a little work this code could be modified for Doctrine. Here’s how we map a form submission to a set of object(s) and here is mapping a object to the form

One thing I want to warn the community at large about is I’m seeing what feels to me like a trend in PHP to conform. You could argue that this very blog post is me, in a way admitting defeat and conforming, but I want to state the obvious that you always have a choice. It seems like many people are choosing to use part of a framework they have already installed instead of challenging whether or not it is the best tool for the job. Just because a filter class is included in Zend Framework doesn’t mean you have to use it. Just because ezComponents has a workflow component doesn’t mean you must employ it. Fact is AptitudeCMS includes Zend Framework, has some PEAR libraries and even some things like MVCnPHP. You can argue bloat, file sizes, which is valid but I’m confident you can still cherry pick the best parts of a framework to give you something you can work with long term. I’ve used Flexy instead of Smarty, MVCnPHP instead of Zend Framework and Propel instead of Doctrine. Some could see those as one bad decision after another but it’s simply the result of a cherry picking exercise I did long ago. Today I’d likely make different decisions but I can tell you I wouldn’t put all my eggs in one basket. Nor should you.

This blog entry, a self admission to failure, hopefully didn’t upset anybody along the way. To be clear I’m the only one who failed here. Maybe “fail” is too harsh a word as I’m quite happy to make this transition but I want to be clear to Dirk Haun, the Geeklog Project and those of you whom I’ve brushed IDE’s with are all people I very much respect. I hate “losing” and this feels like a loss and will always feel that way. If anybody makes use of any of these suggestions please pass that along in an email to me. It will take a bit of the sting off.

1. CSRF Protection – If your views use the built in support for Flexy (via the class BaseViewFlexy) then your forms will automatically have a Cross Site Request Forgery token added to the form as a hidden field along with having two cookies set to check the validity of that CSRF token. The CSRF support is enabled by default which means all MVCnPHP commands that extend BaseCommand will automatically check the token for you.
2. We’ve added the use of the __DIR__ magic PHP variable in the requirement statements. Opcode caches, particularly APC optimize better when require’s are used with absolute paths.

As always we encourage you to download and install MVCnPHP. For faster notification on MVCnPHP news and releases be sure to follow AptenoLC on Twitter

If there is anything you should gleam from this article for future reference, Leopard comes with a 64bit Apache installation. Thus if I go into the PHP 5.3 source and tried, say:

#>./configure --with-png --with-tiff --with-jpeg \
--with-gd --enable-soap --with-apxs2

It my configure, may even compile but when you install and restart Apache you’d get errors about the PHP module being of the wrong architecture. I confirmed this using the “file” command. After that I started down the path of “well, let’s just compile to 64 bit”. I did find references that suggest trying to add CFLAGS=”-arch x86_64″ to your configure statement but that didn’t work either. You might be able to get this working if you dink with it enough, however, I was in “get it working” mode. I did find this blog post by Marc Liyanage which gives more details into what is going on. Turns out this 64-bit problem is much bigger than just PHP because I was unable to get the fink libraries for stuff like libpng, etc to compile to 64bit. Now maybe you can do this by downloading the individual packages and compiling them one-by-one but I’m far too lazy for that.

The fix? Run Apache in 32-bit mode. Not knowing anything about Mac and that some binaries are compiled to support multiple architectures I was hanging out in #apache on irc.freenode.net trying to figure out the best way to compile Apache under OS X. At the same time I posted to macosxhints.com and got a very simple, elegant answer that didn’t require me to download and recompile Apache:

sudo cp /usr/sbin/httpd /usr/sbin/httpd-fat
sudo lipo /usr/sbin/httpd -thin i386 -output /usr/sbin/httpd

After that using my standard ./configure worked just fine and I now have PHP 5.3a1 working beautifully. That said, I’d love to hear from anybody that has managed to get PHP 5.3 (and required libraries) compiled using the 64-bit Apache.

The order of where things showed up in this book was a problem for me. Part 2 is on Testing and Documentation while Part 4 is dedicated to the Model-View-Controller (MVC) design pattern. At the very least Part 4 should follow Part 1′s discussion on design patterns and, better yet, all of Part 4 should have been merged with Part 1. That said, I was pretty happy with the talk on testing and documentation. Kevin does a good job talking through the use of PHPDoc and PHPUnit both of which should be in any PHP developer’s toolbox. Part 2 also has a good discussion on Reflection which, back to the organization of the book, could have probably been a better fit in the discussion of object oriented programming, though, he did have a lengthy section on parsing reflection-based documentation data. Kevin did a great job covering the topic of reflection but I was a bit surprised to see no mention of how using reflection can negatively impact performance of your PHP application. Which brings me to my biggest criticism of the book.

With a title like “Pro PHP” I’d expect a few chapters dedicated to performance, scalability and security. While I’m a huge fan of object oriented programming and know a bit about the value software frameworks they often work counter to scalability and performance. This book had no mention of opcode caching, no discussion on application caching, database caching and the use of shared memory (RAM). Maybe that is intended to be another book in and of itself? Nonetheless, having a chapter or two on security is something that is needed if we want to fix the internet. Indeed application security is the subject of many books so I wouldn’t expect a book on “Pro PHP” to be exhaustive but today’s hackers are trending toward looking for applications holes instead of networking holes because a) they are usually easier to exploit and b) there are a lot of applications looking to be exploited. XSS, CSRF, SQL Injection, etc are all things developers need to be conscious of when writing code (regardless of language) and ignoring security is this book seems to be a bit irresponsible. I know, I know…tough words and, again, you can only effectively cover so much in one book but security definitely should have made the cut.

Part 3 covered the The Standard PHP Library (SPL). This quite possibly was one of the strongest points of the book. SPL’s top features are iterators of all sorts, file and directory handling and advanced array handling. Kevin covers all this and more in great detail. I was surprised to learn how many different types of iterators supported by SPL and I would recommend this entire book based on how well SPL was covered.

Part 4 of Pro PHP does a good job covering the most essential parts of the Zend Framework particularly they MVC implementation, logging and access control. In the world of PHP frameworks Zend is becoming more of a household name but I’d simply add that there are a lot of PHP frameworks out there. While the author is clearly a fan of the Zend Framework and does a good job showcasing some of it’s strengths please leave knowing they aren’t they only game in town.

AJAX/JSON and Web Services via SOAP are covered by Part 5 of the book. AJAX and JSON in PHP can also be it’s own book given all the AJAX libraries out there. Kevin does a great job giving a quick overview of AJAX and talks a bit on how to use it with the Zend Framework. This will only wet your appetite on the subject but I felt it was a pretty good start. The following chapters focused exclusively on Web Services and SOAP. PHP5 has solid support for SOAP minus some interoperability issues and Kevin covers this well. As a shameless plug I’d also point anybody doing SOAP-based web services in PHP to check out the PHP SOAP Toolket (PST) which works around some of the interop issues. Additionally I’d also point you to this utility that gives you all the features of PST without having to install a thing. I digress…back to the book. One thing I feel that PHP is really good at is support for REST-based services which is largely ignored by this book. I think in a book like this you can only effectively cover one of either SOAP and REST, however, I would have liked to see REST at least mentioned and a quick comparison of when you might use one versus the other.

This book has also been reviewed by a number of other talented people so please feel free to factor their opinions in with mine to see if this is a book for you. I honestly do feel this book has a place on your bookshelf particularly for those just diving in more advanced PHP development.

    // at the beginning of our application (in a singleton or in
    // index.php at the very least)
    $logger = new Zend_Log($writer);
    $registry->set(?logger? , $logger);

    // Every time you log you have these two lines.
    $logger = Zend_Registry::get(?logger?);
    $logger->log($errorMessage,1);

Not bad, not bad at all. In fact Zend_Registry is a handy little class. But why call Zend_Registry::get() explicitly over and over if you don’t have to? I mean wouldn’t it be nice if you could simply do:

MyLog::log('SomeMessage', Zend_Log::DEBUG);

That’s right, let’s log things statically and let all the magic happen behind the scenes. We’ll do just that with a small bit of code and best of all you won’t even need Zend_Registry (again, great class but why use it if you don’t need it). How? Well you need to use something that acts like Zend_Registry but allows us to log messages statically. To do that we’ll create a new class called MyLog and the first thing is the allow the application (or any plugins) to register their loggers (click read more):
 

public static function registerLogger($loggerName, $zendWriter = '',
    $isDefault = false)
{
    if (!isset(self::$instances[$loggerName])) {
        self::$instances[$loggerName] = new Zend_Log($zendWriter);
    }

    // If we weren't told this is the default logger yet none exists then force it
    if (!self::getDefaultLoggerName() AND !$isDefault) $isDefault = true;
        if ($isDefault) {
            if (isset(self::$defaultLogger)) {
                throw new Exception('Default logger is already defined');
            }
            self::$defaultLogger = $loggerName;
        }
    }

The $loggerName is a logical name given to the logger you are registering. This must be unique. $zendWriter is one of the many Zend_Writer children you can use. Finally $isDefault indicates if the logger given will serve as the default logger. This will allow us to use shorter notation in our application. Ok, once you have this you can register all your loggers:

// You only ever do these once
MyLog::registerLogger('kernel', new Zend_Log_Writer_Stream(getOption('logFile')), true);
MyLog::registerLogger('somePlugin', new Zend_Log_Writer_Stream(getOption('path_logs') .
    'SomePlugin.log'));
MyLog::registerLogger('propel', new Zend_Log_Writer_Stream(getOption('path_logs') .
    'Propel.log'));

This then allow us to log a message with a single line with any of the following

// Log to the default 'kernel' logger with only an informational message.
// Default log level is Zend_Log::INFO
MyLog::log('Kernel starting up');
// Log to plugin's log
MyLog::log('Plugin failed to initialize', Zend_Log::ERR, 'somePlugin');

While the above is nice we can improve by providing simple pass through functions for each Zend_Log log level:

// Same log to the kernel from above but shorter
MyLog::info('Kernel starting up');
// Log to plugin log like above but shorter
MyLog::err('Plugin failed to initialize', 'somePlugin');

If you like all this logging goodness you simply need to grab this file along with Zend_Log and you are on your way. Please note the requires at the beginning of the class I’m providing. It is using a method called getOption() which you will either need to implement or replace it with relative pathing. We do it this way because we’ve optimized our application to use APC which likes a) require instead of require_once and b) absolute paths over relative paths.

1. CSRF solution must apply to any and all forms in the system.
3. CSRF solution must work even in the case where the page served has multiple forms
4. CSRF solution must work for both GET and POST
5. CSRF solution must be applied to all forms without the developer having to make any explicit method calls to CSRF-related functions.

The solution? I’ve basically adapted what Chris Shifflet proposed in this blog entry from a few years ago. For the lazy, his solution involves including a token in each form and then putting the token value and the time the token was created into the user session. Upon submission of the form, the form value is then checked with the session value and then the time the token was used is compared to some sane time-to-live (TTL) value. Having this solution in mind I then added a few more details to the requirements above:

1. The security token must be autogenerated and inserted into each form
2. Each command (we operate in an MVC model) must have the ability to specify where it expects the token to be (e.g. POST or GET). The default value for this must be in the $_POST (in fact I question if using GET at all makes any sense).
3. The solution must not check for the token in the $_REQUEST
4. The solution must allow each command to set the TTL for the token.
5. Should no TTL be explicitly given, the system must use the default of 3 minutes

(click ‘read more’ for the solution)Ok, so armed with those requirements here is how the implementation went. Not unlike most MVC implementations we have a class representing a view (or a single page within the system). We have a few abstract classes in our codebase but the one of most importanc is BaseViewFlexy.php. The class in this page uses the Flexy template engine. In this class there is a compile() method that takes the given Flexy template and compiles it into PHP code. This is the point where we want to insert our security token and the best way to do this was to create our own Flexy compiler that does this work with the following method:

protected function injectSecurityToken($content)
{
    $content = str_ireplace('</form>',
        '<input type="hidden" name="glSecurityToken" /></form>',
    	$content);
    return $content;
}

If you notice above I don’t actually inject the value. Remember that we have bootstrapped the Flexy compile process so the above code ends up in the compiled Flexy template which, again, is PHP code. Now we need to insert the value for the token when we do our normal Flexy variable substitution. To do this our BaseViewFlexy.php file has a compile() method:

public function compile($templateToCompile)
{
    // Compile the flexy template using our custom compiler
    $this->flexyHandle->compile($templateToCompile);
    $this->flexyElements = $this->flexyHandle->getElements();

    // Use Flexy to inject token (if needed)
    if (in_array('glSecurityToken',array_keys($this->flexyElements))) {
    	$this->flexyElements['glSecurityToken']->setValue($this->getSecurityToken());
    }
}

You’ll notice the call to getSecurityToken() above. That is the method where we generate the token, set the token and token creation time in the session:

protected function getSecurityToken()
{
    $token = md5(uniqid(rand(), TRUE));
    $_SESSION['glSecurityToken'] = $token;
    $_SESSION['glSecurityTokenTime'] = time();
    return $token;
}

Ok, so to this point we have insert the HTML hidden field that will hold the security token into our compiled Flexy template and we have set the appropriate value for the token and added the token and token creation time to the session. Because we did all this by overriding methods Flexy uses natively we have guaranteed this code will be executed for every form without the developer having to explicitly call anything. Now we need to do the checks upon submission of the form itself.

In our MVC implementation as with our View we have the notion of a command. Specifically we have an abstract class in BaseCommandUser.php that is aware of the user session already. All we need to do is add the security check for the token to it’s constructor:

public function __construct($urlArgs = null)
{
    $this->user = unserialize($_SESSION[getOption('user_session_var')]);

    if ($this->getUserRequired() AND ($this->user->getUserId() == 2)) {
       // NOTE this makes use of the global forward feature in MVCnPHP
       throw new Exception('doForward:login');
    }

    if (!$this->authorizedToRun()) {
        throw new Exception('You do not have sufficient privileges to perform this action.
            Please note that all attempts to illegally perform actions are logged');
    }

    // We may have data submitted to us.  Check the security token
    $this->doSecurityTokenCheck();

    parent::__construct($urlArgs);
}

As you can see above we call doSecurityTokenCheck() which will throw an exception if it should fail. There are two reasons for failure 1) the token in the form doesn’t match the one in the session and 2) the token has expired:

    protected function doSecurityTokenCheck($inputArray = self::INPUT_POST)
    {
    	if (!$this->doSecurityTokenChecks) return;

    	$arrayToCheck = array();

    	if ($inputArray == self::INPUT_POST) {
    		$arrayToCheck = &$_POST;
    	} else {
    		if ($inputArray == self::INPUT_GET) {
    			$arrayToCheck = &$_GET;
    		}
    	}

    	// If we didn't get a token in the session before now set one
        if (!isset($_SESSION['glSecurityToken'])) {
			$_SESSION['glSecurityToken'] = md5(uniqid(rand(), TRUE));
        }

        if ($arrayToCheck['glSecurityToken'] == $_SESSION['glSecurityToken']) {
        	// Valid token.  Validate age (if needed)
        	$tokenAge = time() - $_SESSION['glSecurityTokenTime'];
        	if (is_null($this->securityTokenTTL)) $this->setSecurityTokenTTL();
        	if (!($tokenAge <= $this->securityTokenTTL)) {
        		throw new Exception('The form you submitted has expired.  Please go back and try again');
        	}
        } else {
        	Geeklog_Log::log('Cross site forgery request (CSFR) detected', Zend_Log::CRIT);
        	throw new Exception('Cross site forgery request (CSFR) detected.  Please note all
        		such attempts are logged.');
        }
        return;
    }

As you can see from above you can set the class member doSecurityTokenChecks to avoid doing these checks at all (i.e. in the case of a view with no form fields). There is also a class member, securityTokenTTL, which can be set on a command-by-command basis. For sanity sake we default to 3 minutes.

That’s it! I don’t pretend this is perfect code but it does work and is in line with Chris Shiflett’s approach which I liked. With a little bit of work we were able to build in protections against CSRF, which I don’t claim to be 100% complete but do make such attacks considerably harder, and it is done in a way that secures all forms without the developer having to explicitly call anything. A true win-win in my opinion!