1. Was the user trying to access something in the admin section?
2. Was the user logged in as admin?

I still needed to add the mechanism for logging in, but there was no need for an access control list, and the implementation of the Access Control Plugin was much simpler.

As before, the plugin needs to be registered in the configuration file:

resources.frontController.plugins.accessControl = 
  "Application_Plugin_AccessControl"

The implementation of the plugin is much simpler, however:

<?php
class Application_Plugin_AccessControl extends Zend_Controller_Plugin_Abstract
{
  public function preDispatch(Zend_Controller_Request_Abstract $request)
  {
    // Get the current user role
    $role = Application_Model_Identity_Current::getRole();
 
    // Get the request module
    $module = $request->getModuleName();
 
    // Determine whether the user is allowed to access the module
    $accessDenied = false;
 
    if ($module == 'admin' && $role != 'admin')
      $accessDenied = true;
 
    // If access is denied, redirect to the login page
    if ($accessDenied)
    {
      $request->setModuleName('default');
      $request->setControllerName('login');
      $request->setActionName('index');
    }
  }
}

The workings of the class should be self-evident from the comments.

Let us start with the plugin itself. It is called Application_Plugin_AccessControl and located in the application/plugins directory. To locate the class definition, the autoloader strips the standard prefix Application_, which is declared in the configuration file, from the class name, then maps the Plugin_ part to that directory. The plugin itself is declared in the configuration file as follows:

resources.frontController.plugins.accessControl = "Application_Plugin_AccessControl"

This ensures that the plugin is initialised and used during the despatch process.

The plugin itself is derived from Zend_Controller_Plugin_Abstract and implements the standard preDispatch method:

class Application_Plugin_AccessControl extends Zend_Controller_Plugin_Abstract
{
  public function preDispatch(Zend_Controller_Request_Abstract $request)
  {
    // TODO: Apply access control
  }
}

By implementing this method, the plugin will be called via it before any request is despatched to the relevant controller. This allows access control to be applied by redirecting a request, if the user is after something that it out of bounds.

The process of applying access control involves a series of steps. These are given below.

Step 1: Get the authentication object. This is used to determine whether the user is logged in, and if so, then as whom.

    $auth = Zend_Auth::getInstance();
    $auth->setStorage(new Zend_Auth_Storage_Session());

Step 2: Get the access control list. This is done by using the static getAcl method of the Application_Model_Acl class.

    $acl = Application_Model_Acl::getAcl();

Step 3: Get the current user role and determine whether the user is logged in.

    $role = Application_Model_Identity_Current::getRole();
    $loggedIn = true;
 
    if (!$acl->hasRole($role))
    {
      $role = 'guest';
      $loggedIn = false;
    }

Step 4: Use the module name and controller name as the resource against which to check. Note that the module is added as a prefix, if it is not the default module.

    $module = $request->getModuleName();
    $controller = $request->getControllerName();
 
    if ($module == 'default' || $module == '')
      $resource = $controller;
    else
      $resource = $module . ':' . $controller;

Step 5: Use the action name as the privilege. The privilege is a sub-division of a resource, to allow finer-grained control of access. In our case, we use it to distinguish between different actions under the same controller.

    $privilege = $request->getActionName();

Step 6: If the resource is not in the ACL, use the default resource and privilege.

    if (!$acl->has($resource))
    {
      $resource = 'index';
      $privilege = 'index';
    }

Step 7: Check whether the user is allowed access to the specified resource. If not, display the home page instead if the user is logged in, otherwise display the login page.

    if (!$acl->isAllowed($role, $resource, $privilege))
    {
      if ($loggedIn)
      {
        $request->setModuleName('default');
        $request->setControllerName('index');
        $request->setActionName('index');
      }
      else
      {
        $request->setModuleName('default');
        $request->setControllerName('login');
        $request->setActionName('index');
      }
    }

First we need a line like this in the configuration file to allow the bootstrapper to find our plugin:

pluginPaths.Application_Resource = APPLICATION_PATH "/resources"

The key Application_Resource indicates the prefix given to the class that implements the plugin, minus its trailing underscore. The value indicates the location in which the plugins with this prefix are stored.

The class itself is implemented in Registry.php in the resources directory. It contains the following code:

<?php
class Application_Resource_Registry 
  extends Zend_Application_Resource_ResourceAbstract
{
  public function init()
  {
    // Get the registry object
    $registry = Zend_Registry::getInstance();
 
    // Get the options that should be placed in the registry
    $options = $this->getOptions();
 
    // Add the options to the registry
    foreach ($options as $index => $value)
    {
      $registry->set($index, $value);
    }
 
    return $registry;
  }
}

The code should be fairly self-explanatory. The options are key/value pairs retrieved from the configuration file, e.g.

resources.registry.phone = "phone number"

In the above case, the value “phone number” is stored under the index phone in the registry.

The key things is that it is possible to use constants in the configuration file. The first step is therefore to define a constant to represent the current date stamp in htdocs/index.php:

// Define current date
define('DATESTAMP', date('Y-m-d'));

This should come after the definitions of APPLICATION_PATH and APPLICATION_ENV (see the earlier post on index.php).

This constant can now be used in the configuration file (application/configs/application.ini) to declare the log filename, along with the other necessary settings:

resources.log.stream.writerName = "Stream"
resources.log.stream.writerParams.stream = 
  APPLICATION_PATH "/logs/log_" DATESTAMP
resources.log.stream.writerParams.mode = "a"

To use the logger, you can fetch the object created like this from within the controller:

$bootstrap = $this->getInvokeArg('bootstrap');
$log = $bootstrap->getResource('log');

Then use the logger in the normal fashion, e.g.

$log->err('Page not found');

The bootstrap class location and name is specified in the configuration file; see Bootstrapping the Application: Configuration File Overview.

The basic skeleton of the class is as follows:

class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
{
  // Add the initialisation methods here
}

Note that Zend_Application_Bootstrap_Bootstrap is the base class; this adds the basic functionality, which essentially involves registering and initialising the front controller plugin.

The class can contain methods that initialise resources programmatically (as opposed to via the configuration file). These methods all have the prefix _init and return a reference to the resource that is initialised. The sample application contains one such method:

protected function _initAutoload()
{
  $autoloader = new Zend_Application_Module_Autoloader(array(
    'namespace' => 'Default_',
    'basePath'  => dirname(__FILE__),
  ));
 
  return $autoloader;
}

This sets up the autoloader to look for classes with the prefix Default and located in the application directory. In addition, the autoloader class automatically declares a number of additional directories and associated prefixes:

Prefix: Model_DbTable    Directory: models/DbTable
Prefix: Form             Directory: forms
Prefix: Model            Directory: models
Prefix: Plugin           Directory: plugins
Prefix: Service          Directory: services
Prefix: View_Helper      Directory: views/helpers
Prefix: View_Filter      Directory: views/filters

These prefixes and directories are applied to the base prefix and directory, and use the standard Zend Framework autoloader conventions. For instance, the class Default_Model_Db_Blog uses the prefix Default followed by the prefix Model, and is therefore located in the application/models/Db directory in a file called Blog.php; this is because the root directory, associated with Default, is application, the directory associated with Model is models, and the remaining part of the name (Db_Blog) decomposes to Db/Blog.php.

Zend_Application_Resource_View is a common plugin to replace. This is because it doesn’t allow you to set the DOCTYPE. The sample application contains a replacement for this plugin, which sets this, among other things.

Default_Resource_View has the following basic skeleton:

class Default_Resource_View
  extends Zend_Application_Resource_ResourceAbstract
{
  // Add class methods and variables here
}

Zend_Application_Resource_ResourceAbstract is the base class, as is required.

A variable is declared to store the Zend_View:

protected $_view;

Zend_Application will call the init method of the class to retrieve the resource it initialises. The class uses the singleton pattern to implement this.

First, the init method is declared; this in turn calls the getView method, which will create the Zend_View if necessary:

public function init()
{
  return $this->getView();
}

The getView method starts by checking whether the Zend_View has already been created; if not, it gets the options from the configuration file and creates the view:

public function getView()
{
  if (null === $this->_view)
  {
    // Get the resource options
    $options = $this->getOptions();
 
    // Create the view
    $view = new Zend_View();

The method then checks whether the doctype option is set; if it is, it sets the view’s doctype to the specified value:

    // Set the doctype
    if (isset($options['doctype']))
    {
        $view->doctype($options['doctype']);
    }

This option is set as follows in the sample application:

resources.view.doctype = "XHTML1_STRICT"

The next option to check is the helpers option; this allows the application to add view helper paths to the view; these specify the possible prefixes and locations of view helper classes:

    // Add the custom view helper paths
    if (array_key_exists('helpers', $options))
    {
      foreach ($options['helpers'] as $key => $value)
      {
        $view->addHelperPath($value, $key);
      }
    }

The view helpers are declared as key/value pairs in the configuration file; the prefix is the key and the location the value:

resources.view.helpers.Default_View_Helper = 
  APPLICATION_PATH "/views/helpers"
resources.view.helpers.ZendX_JQuery_View_Helper = 
  "ZendX/JQuery/View/Helper"
resources.view.helpers.Test_View_Helper = 
  APPLICATION_PATH "/tests/helpers"

The first set of helpers are the generally-used helpers defined by the application; the second set are those in the Zend extras jQuery module; the third set are used exclusive to the test controller. We shall see examples of these in use in later posts.

The last option is placeholders. These are pieces of text that are used in more than one place in the layout and view scripts, and which may need to be changed, such as the contact phone number. They are defined in the configuration file as key/value pairs:

    // Add the placeholders
    if (array_key_exists('placeholders', $options))
    {
      foreach ($options['placeholders'] as $key => $value)
      {
        $view->placeholder($key)->set($value);
      }
    }

The following placeholders are defined in the configuration file:

resources.view.placeholders.phoneNumber = "+44 (0)1403 753721" 
resources.view.placeholders.copyrightDate = "2009"

Finally, the Zend_View is attached to the View Renderer and a reference to it is stored in $_view:

    // Set the view renderer to use the view
    $viewRenderer = Zend_Controller_Action_HelperBroker::getStaticHelper
      ('ViewRenderer');
    $viewRenderer->setView($view);
 
    $this->_view = $view;
  }

That ends the block that is executed when a Zend_View does not yet exist. At this point, a Zend_View has been created, and the reference to this is returned from the method:

  return $this->_view;
}

One very useful class is Zend_Log, which provides a handy mechanism for logging application errors or user activity. I have created a custom resource plugin called Default_Resource_Log, which handles the initialisation of a Zend_Log, and storage of it in the registry for future retrieval.

To use custom resource plugins, you need to register a plugin prefix and associated directory. In the case of the sample application, the prefix is Default_Resource and the directory is resources; these are added to the configuration file like this to perform the registration:

pluginPaths.Default_Resource = APPLICATION_PATH "/resources"

The plugin itself is implemented in a file called Log.php, which is in the resources directory. Note that although the class is called Default_Resource_Log, the prefix is excluded when naming the file in which it is contained.

The basic class skeleton is as follows:

class Default_Resource_Log 
  extends Zend_Application_Resource_ResourceAbstract
{
  // Add class methods and variables here
}

Note that Zend_Application_Resource_ResourceAbstract is the base class for resource plugins.

It has a member variable used to store the Zend_Log:

protected $_log;

Zend_Application will call the init method of the class to retrieve the resource it initialises. The class uses the singleton pattern to implement this:

public function init()
{
  return $this->getLog();
}
 
public function getLog()
{
  if (null === $this->_log)
  {
    $options = $this->getOptions();
    $file = str_replace('%d', date('Y-m-d'), $options['file']);
    $log = new Zend_Log(new Zend_Log_Writer_Stream($file));
    Zend_Registry::set('Zend_Log', $log);
    $this->_log = $log;
  }
 
  return $this->_log;
}

If Zend_Log has already been created, it returns the reference stored in $_log; otherwise, it creates the Zend_Log, stores a reference to it and returns that.

The reference to Zend_Log is also stored in the registry under the key Zend_Log; this allows it to be retrieved later by:

$log = Zend_Registry::get('Zend_Log');

Note the call to getOptions; this allows the resource plugin to retrieve any settings in the configuration file that apply to it. Here, the following line has been added to the configuration:

resources.log.file = APPLICATION_PATH "/logs/application-%d.log"

This sets the location of the log file. Note that the resource plugin will look for the string %d in the name and replace it with the current date; this leads to a different log file being created every day.

Note that it is necessary to add at least one line relating to the resource plugin to the configuration file in order to have it initialised; if there were no parameters, you would just add:

resources.log[] =

Zend_Application_Resource_Router, the standard router resource plugin, presents a simple mechanism for adding routes to the router. For each route you wish to add, you need to add a block like this to the configuration file:

resources.router.routes.sitemap.route = "sitemap.xml"
resources.router.routes.sitemap.defaults.controller = "sitemap"

The sub-element after routes (here sitemap) is set to a unique name for the route. There are many parameters that can be set; here we set two:

• route: This represents the actual request, which is for sitemap.xml.
• defaults: This represents what the request is converted to; here we only specify the controller, but it is also possible to specify other things such as the module, action or parameters.

Now any request for sitemap.xml will be redirected to the index action of the sitemap controller.

We will look at how the request is actually handled in a later post.

In the sample application, each of the site pages is added via a block of settings in the configuration file, which take the following form:

resources.navigation.pages.home.type = "Zend_Navigation_Page_Mvc"
resources.navigation.pages.home.label = "Home"
resources.navigation.pages.home.id = "home_page"
resources.navigation.pages.home.controller = "index"
resources.navigation.pages.home.action = "index"

The sub-element after pages (here home) is set to a unique name for the page. The purpose of all the settings for this element are as follows:

• type: This inidicates how the page location is represented. It is either Zend_Navigation_Page_Mvc, when the module/controller/action associated with the page is specified, or Zend_Navigation_Page_Uri, when a straightforward URI for the page is given.
• label: This is the string used when rendering the page name.
• id: This is the unique ID used to identify the page.
• controller: This is the controller associated with the page (see type above).
• action: This is the action associated with the page (see type above).

All the pages are of the type Zend_Navigation_Page_Mvc; the other settings are as follows:

• home: Home, home_page, index, index
• about: About Us, about_page, index, about
• contact: Contact Us, contact_page, index, contact
• blogs: Our Blogs, blogs_page, index, blogs

Zend_Application_Resource_Navigation will create a container object. It will then populate it with page objects based on the settings in the configuration file.

We will look at how the Zend_Navigation object is used in rendering the page navigation and sitemap in later posts.

To use Zend_Layout, you need to specify the location of the layout scripts, then invoke Zend_Layout::startMvc(). The standard resource plugin Zend_Application_Resource_Layout is used by Zend_Application to automate this process. To use this plugin, you should add the following line to the configuration file:

resources.layout.layoutPath = APPLICATION_PATH "/layouts/scripts"

This specifies the location of the layout scripts. If your scripts are in a different location, you should change the value of layoutPath.

We shall look at Zend_Layout in more detail in later posts.