1. Prefix a relative url path with a host.
2. Rotate a set of relative url's through a given number of cdn hosts.

We currently use Zend Framework at work, so it is only logical we use as much of the framework as possible.  The straight forward approach is to extend Zend_View_Helper_Abstract and create a few functions to fill the requirements.  There are few problems with this approach.  The first is function creep.  We know we need to prefix http://www.hautelook.com and https://www.hautelook.com, but there may be more later.  We may decide to use something like https://ssl.hautelook.com or require another subdomain like http://ftp.hautelook.com.  This would require us to create another function, write some unit tests for it and finally send it through QA.  This issue is even more compounded with the cdn rotation function.

Another problem is that we need absolute url's in some of our business logic.  We have webservices that serve up XML or JSON that contain locations to such as images or a catalog.  We want these services to take advantage of the absolute url logic too.  If we implement a view helper, then the service layer becomes coupled to the view in order to reuse the logic.

Enter PHP 5.3, functional programming and an inspirational post from Eli White.  We can use the factory method pattern and closures to meet all the requirements and isolate the parts that change.  Read these posts if you are not familiar with functional programming in PHP.

class Crimson_Url
{
    public static function absolute($host)
    {
        return function($path) use ($host) {
            return "{$host}{$path}";
        };
    }
 
    public static function rotate($subdomain, $host, $rotations, $protocol='http')
    {
        $current = 0;
 
        return function($path) use (&$current, $subdomain, $host, $rotations, $protocol) {
            if ($current == $rotations) {
                $current = 1;
            } else {
                $current++;
            }
 
            return "{$protocol}://{$subdomain}{$current}.{$host}{$path}";
        };
    }
}

The absolute function demonstrates how simple, yet powerful, closures can be.  The absolute function is creating a function that concatenates to strings together: a host name and a relative url.  Here is how we would use this:

$www = Crimson_Url::absolute('http://www.example.com');
$ssl = Crimson_Url::absolute('https://www.example.com');
 
echo $www('/foo.jpg'), PHP_EOL;
echo $ssl('/secure.php'), PHP_EOL;

Output:

http://www.example.com/items.php

https://www.example.com/secure.php

Take this one step further and think about how you can use the HTTP_HOST or HTTP_REFERER values from $_SERVER to make absolute URL generation almost completely automatic.

The rotate function is slightly more complex.  The $current variable is being declared in the factory method and passed by reference.  We must explicitly pass this by reference otherwise PHP will pass it by value and the value of $current will be 1 everytime.  Here is how we would use the rotater:

$cdn = Crimson_Url::rotate('cdn', 'hautelook.com', 3);
$sslCdn = Crimson_Url::rotate('cdn', 'hautelook.com', 3, 'https');
 
echo $cdn('/foo.jpg'), PHP_EOL;
echo $cdn('/bar.jpg'), PHP_EOL;
echo $cdn('/baz.jpg'), PHP_EOL;
echo $cdn('/bob.jpg'), PHP_EOL;
 
echo $sslCdn('/foo.jpg'), PHP_EOL;
echo $sslCdn('/bar.jpg'), PHP_EOL;

Output:

http://cdn1.hautelook.com/foo.jpg

http://cdn2.hautelook.com/bar.jpg

http://cdn3.hautelook.com/baz.jpg

http://cdn1.hautelook.com/bob.jpg

https://cdn1.hautelook.com/foo.jpg

https://cdn2.hautelook.com/bar.jpg

Notice how there are no problems with static variable conflicts. Each function is independent and can be used for completely different tasks.

The complete source code, with tests and documentation, can be found here: http://github.com/hradtke/crimson/tree/master/Crimson_Url

All this talk of functional language features is great, but Lithium is still in development, Zend Framework 2.0 is a ways away, you have an upcoming project deadline and you want to know how this stuff can help you now.  Easy: go read or watch JavaScript examples.  Seriously.  Watching Douglas Crockford's videos on YUI theatre or reading through ExtJS source code can give you really good insight into the power of functional language features.  The syntax may be different, but the core ideas are the same.

The new functional feel of PHP seems to have started a trend towards a unified constructor.  This has been a common practice in the JavaScript community for some time.  The great thing is that the PHP array is very similar to the JavaScript object.  In fact, the JSON extension to PHP makes them completely interchangeable.  Here is a quick example of one unified constructor implementation in PHP:

<?php
 
$p = array(
    'a' => 'hi',
    'adder' => function($n) { return $n + 1; },
    'c' => 3,
    'd' => new stdClass
);
 
class base {
    function __construct(array $params)
    {
        foreach ($params as $key => $value) {
            $this->$key = $value;
        }
    }
}
 
class foo extends base { }
 
$foo = new foo($p);

I have a bunch of ideas (some great, some maybe not so great) that I plan on implementing using lambda functions and closures. I will be adding new components to my Crimson library and discussing them here.

I first attempted to mock Zend_Db_Table_Row using PHPUnit's _getMock method.  This proved to be an exercise in futility.  I did not want the class to connect to the database to verify whether or not the columns were valid.  After a few frustrating hours, I started to wonder how Zend was unit testing Zend_Db_Table_Row.  So I downloaded the full version of the latest Zend Framwork and started poking around.  I stumbled upon My_ZendDbTable_Row_TestMockRow hiding away in ZendFramework-1.9.5/tests/Zend/Db/Table/_files/My/ZendDbTable/Row/TestMockRow.php.  I will not go into what was done to make it a usable mock, but I will show you how to use it.

<?php
 
require_once 'PHPUnit/Framework/TestCase.php';
require_once 'tests/Zend/Db/Table/_files/My/ZendDbTable/Row/TestMockRow.php';
 
class TestMockRowTest extends PHPUnit_Framework_TestCase
{
    public function testRowHasIdValue()
    {
        $data = array(
            'data' => array(
                'first_name' => 'Herman',
                'last_name' => 'Radtke',
                'email' => 'herman@example.com'
            )
        );
 
        $row = new My_ZendDbTable_Row_TestMockRow($data);
        $this->assertEquals('Herman', $row->first_name);
        $this->assertEquals('Radtke', $row->last_name);
        $this->assertEquals('herman@example.com', $row->email);
    }
}

Creating a mock row object is much like hardcoding an array.   Define an array that has a single key 'data' that contains an array as a value.  Inside this array, the database column name is the array key and the database column value is the array value.

That class works great for mocking a single row object, but I still needed a solution for multiple row objects.  I expected to find a class similar to My_ZendDbTable_Row_TestMockRow for the purposes of testing Zend_Db_Table_Rowset, but none existed.  Fortunately, it took only a few minutes to create my own.  All one has to do is specify the name of the row class for the rowset class to use.

<?php
 
require_once 'PHPUnit/Framework/TestCase.php';
require_once 'library/Zend/Db/Table/Rowset/Abstract.php';
require_once 'tests/Zend/Db/Table/_files/My/ZendDbTable/Row/TestMockRow.php';
 
class ZendDbTableMockRowset extends Zend_Db_Table_Rowset_Abstract
{
    protected $_rowClass = 'My_ZendDbTable_Row_TestMockRow';
}
 
class RowsetTest extends PHPUnit_Framework_TestCase
{
    public function testConstructor()
    {
        $rowset = new ZendDbTableMockRowset(array(
            'data'=> array(
                array(
                    'id' => 123456
                ),
                array(
                    'id' => 123457
                ),
                array(
                    'id' => 123458
                ),
                array(
                    'id' => 123459
                ),
                array(
                    'id' => 123460
                )
            )
        ));
 
        $id = 123456;
        foreach ($rowset as $row) {
            $this->assertTrue(($row instanceof My_ZendDbTable_Row_TestMockRow));
            $this->assertEquals($id, $row->id);
            $id++;
        }
    }
}

The array passed to the mock rowset has a similar structure to the one we used above.  The only difference is that we have multiple arrays, inside the 'data' array, each representing one row.   For testing purposes, I created an 'id' field.   I normally would not ever use an artificial key field inside a business logic class since that value is very dependent on the database.

I created a ZendDbTableMockRowset class in my projects test/mocks directory so I can use it in multiple test files.  I also copied My_ZendDbTable_Row_TestMockRow into the test/mocks directory so I would not be dependent on the external tests from Zend Framework.  Now mocking Row or Rowset objects is just as fast as mocking arrays.

eAccelerator is an opcode cache.  An opcode cache saves the compiled version of a script so PHP does not have to parse it again.  eAccelerator also strips out comments from the script by default.  That means once your script gets cached, the Zend_Soap_AutoDiscover class has no way of correctly auto-generating the WSDL.

Fortunately, there are some easy solutions to this problem.  The easiest is to configure eAccelerator 0.9.6 to not strip out the comments.  When compiling eAccelerator, specify the --with-eaccelerator-doc-comment-inclusion switch in the configure script.  Install the new compiled version and make sure to clean out your existing cache directory.

Now if you are running eAccelerator 0.9.5, like me, and are unable to upgrade there is still hope.  eAccelerator comes with some ini settings that allow us to not cache scripts. Using the eaccelerator.filter setting, we can tell eAccelerator to ignore scripts by filename. You can set it in your php.ini file or just specify it at runtime:

ini_set('eaccelerator.filter', '!foo/Bar.php !baz.php');

With comments preseved, the Zend_Soap_AutoDiscover class will be able to properly generate the WSDL.

I favor design by contract so I can properly type-hint method parameters.  A framework should be written in a way I can safely extend the crap out of.  This is the exact use case of interfaces.

Universal constructors make the code harder to read.  I see this as a sign that inheritance is being used way too much.  Compose people, compose!

The registry pattern is not any better than a singleton.  They both have global scope.

I do like that there are so many ways to inject dependencies.  The MVC framework is also pretty nice.

Note that this a very minimal example of how I handle authentication. Please make sure to completely implement, document and test before putting this on a production server.

Stefan's suggested implementation is to extend the Zend_Controller_Action class to create a custom controller class and use the init() method to determine if the user is logged in. Developers are expected to then extend this new class to create specific controllers. The obvious problem with this approach, as Stefan mentions, is that anyone who overloads the init() method must make sure to call the parent's init() method. If security relies on an individual developer remembering to call the correct methods, then the system is not very secure. Stefan makes a comment similar to this in the XSS section of his presentation.

I think the better solution to handle the authentication is to create a controller plugin. The authentication controller plugin is registered in one spot, the bootstrap, thus making it much more reliable. There really isn't much more work to do to use a plugin either.

Start by extending the Zend_Controller_Plugin_Abstract class.

class My_Authentication extends Zend_Controller_Plugin_Abstract
{
    public function preDispatch(Zend_Controller_Request_Abstract $request)
    {
        $auth = Zend_Auth::getInstance();
        if ($auth->hasIdentity()) {
            return;
        }
 
        self::setDispatched(false);
        // handle unauthorized request...
    }
}

In the bootstrap, make sure to register the plugin before calling the front controller's dispatch() method.

$controller = Zend_Controller_Front::getInstance();
$controller->registerPlugin(new My_Authentication());
$controller->dispatch();

The above method works fine if your login page is outside your MVC routing. If you use a login controller, there is some more work to do. A white-list of controllers and actions must be maintained to signal the authentication adapter that authentication is not required. I keep the white-list as a hard-coded array inside the authentication plugin class itself. Our class then becomes:

class My_Authentication extends Zend_Controller_Plugin_Abstract
{
 
    private $_whitelist;
 
    public function __construct()
    {
        $this->_whitelist = array(
            'index/login'
        );
    }
 
    public function preDispatch(Zend_Controller_Request_Abstract $request)
    {
        $controller = strtolower($request->getControllerName());
        $action = strtolower($request->getActionName());
        $route = $controller . '/' . $action;
 
        if (in_array($route, $this->_whitelist)) {
            return;
        }
 
        $auth = Zend_Auth::getInstance();
        if ($auth->hasIdentity()) {
            return;
        }
 
        self::setDispatched(false);
        // handle unauthorized request...
    }
}