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');
      }
    }

The skeleton code of the class is as follows:

class LoginController extends Zend_Controller_Action
{
  public function indexAction()
  {
    // TODO: Handle login attempt
  }
 
  public function logoutAction()
  {
    // TODO: Handle logout
  }
}

Let us look at the index action function, which is concerned with rendering the login form and handling login attempts made using it.

The function starts by creating a login form object:

    // Create the login form object
    $loginForm = new Application_Form_Login();

The implementation of this class will be discussed in a subsequent post.

The function now needs to check whether the form has been POSTed back to the application:

    // Check whether the user has submitted the login form
    $request = $this->getRequest();
 
    if ($request->isPost())
    {
      // TODO: Handle form being submitted
    }

If he has been submitted, the application needs to perform some basic validation, to check that the user has entered a username and password; if this validation fails, the cause is passed to the view script:

      // Validate form
      if ($loginForm->isValid($request->getPost()))
      {
        // TODO: Perform authentication of username and password
      }
      else
      {
        $error = $loginForm->getFirstFormError();
        $this->view->errorMessage = $error['message'];
        $this->view->errorField = $error['field'];
      }

If the submitted data passes this basic validation, the application needs to authenticate the username and password. If this is successful, the user is redirected to an appropriate page; otherwise, an error message is passed to the view script:

        // Get submitted values
        $values = $loginForm->getValues();
 
        // Attempt login
        $dbAdapter = $this->getInvokeArg('bootstrap')->getResource('db');
        $log = $this->getInvokeArg('bootstrap')->getResource('log');
        $login = new Application_Model_Login($dbAdapter, $log);
 
        if ($login->login($values['username'], $values['password']))
        {
          $this->_redirect('/');
        }
        else
        {
          $this->view->errorMessage = 'Invalid username or password';
          $this->view->errorField = 'username';
        }

Note that the authentication code is encapsulated inside a class (Application_Model_Login) which will be discussed in a subsequent post.

Also note that the application assumes that both the Db and Log resource plugins have been properly initialised by the bootstrapped (e.g. via the configuration file). See here and here for further details of these two resource plugins.

Finally, the form object needs to be passed to the view script:

    $this->view->form = $loginForm;

The view script will be looked at in the next post.

The implementation of the logout action is simpler:

  public function logoutAction()
  {
    $login = new Application_Model_Login();
    $login->logout();
    $this->_redirect('/login');
  }

Again the Application_Model_Login class is used, this time to clear the user’s status as logged in. Then the user is redirected to an appropriate page.

In subsequent posts, I shall look at the various components that need to be created to create a fairly basic login system, and how to combine these components together. These components are roughly as follows:

• Login controller. This handles the login and logout actions by these user.
• Login form. This allows the user to enter a username and password.
• Authentication class. This handles the process of logging in or out.
• Identity class. This handles the current login status of the user, and details of the user’s identity.
• Access Control List class. This specifies what the user can or cannot see and do.
• Access Control plugin. This checks whether the user is allowed to view a particular page, and redirects to the login page if necessary.

The posts won’t be concerned with the implementation of the pages on the site, other than the Login page. However, it will make reference to what those pages might contain or do, if this is relevant to the login process.

First, we need to create the controller class used to field the request for the sitemap. This is called SitemapController and is located in controllers/SitemapController.php. The class has the following skeleton:

class SitemapController extends Zend_Controller_Action
{
  // TODO: Implement the class action handlers here
}

The first action is the index action, which is handled by the follow method of the class:

public function indexAction()
{
  $this->_helper->layout->disableLayout();
}

This disable the standard layout, so that only the XML of the sitemap is rendered.

The accompanying view script file is application/views/scripts/sitemap/index.phtml and contains the following code:

<?php
$this->navigation()->sitemap()->setFormatOutput(true); 
echo $this->navigation()->sitemap();

This takes the pages in the navigator and uses them to generate a sitemap.

Now, if you navigate to http://[your-domain]/sitemap, the sitemap will be rendered in the browser.

Now we need to set up the router, so that a request for http://[your-domain]/sitemap.xml also brings up the sitemap.

To do this, we should add the route to the application configuration file:

resources.router.routes.sitemap.type = "Zend_Controller_Router_Route_Static"
resources.router.routes.sitemap.route = "sitemap.xml"
resources.router.routes.sitemap.defaults.controller = "sitemap"
resources.router.routes.sitemap.defaults.action = "redirect"

We now need to add another action handler to the SitemapController class:

public function redirectAction()
{
  $this->_redirect('/sitemap');
}

The reason for doing this indirect redirection is that if we route directly to sitemap/index, the navigator becomes confused and renders all the URLs in the sitemap incorrectly. You can confirm this by changing the ini file setting above from “redirect” to “index”.

Zend_Paginator works as follows:

1. The paginator is passed either an actual set of data, or a database query that can be used to retrieve the data.
2. The paginator will by default retrieve the first page and 10 items on that page; the page and the items per page can be set at this point if necessary.
3. The paginator can be used to render a navigator, by retrieving the current page and the number of pages.
4. The paginator can be used to render the current page, by iterating over the paginator to retrieve each item in order.

I shall give a concrete example of how this can be implemented below, based on an application I am currently developing.

First, let us start with the controller. In this instance, the controller is user and the action is index. The skeleton for this code is as follows:

class UserController extends Zend_Controller_Action
{
  public function indexAction()
  {
    // Insert implementation here
  }
}

The current page will be passed via the URL as a parameter. The first task in the action handler is therefore to retrieve the page number. If it is not specified, it will default to 1.

    // Get the current page
    $page = $this->getRequest()->getParam('page', 1);

The next step is to construct a Zend_Db_Select object that represents the database query. To do this we need a database adapter; below, we assume that this has been created during the bootstrapping process and can be retrieved via the bootstrap object. The query simply retrieves all records from the user table, ordering them by the user’s display name.

    // Get the boostrap object
    $bootstrap = $this->getInvokeArg('bootstrap');
 
    // Get the database adapter
    $dbAdapter = $bootstrap->getResource('db');
 
    // Create the selection object
    $select = $dbAdapter->select()->from('user')->order('name');

Now we have the select object, we can use it to create the paginator object.

    // Get a Paginator object using Zend_Paginator's built-in factory
    $paginator = Zend_Paginator::factory($select);

We can then set the number of items per page and the current page.

    // Set the number of items to show per page
    $paginator->setItemCountPerPage(5);
 
    // Select the requested page
    $paginator->setCurrentPageNumber($page);

Finally, we should pass the paginator object to the view script.

    $this->view->paginator = $paginator;

The view script used is given below. Note that the application uses Zend_Layout, so only the unique content of the page needs to be generated here.

<h3>User Management</h3>
 
<?php
// Display pagination control
echo $this->paginationControl($this->paginator, 'Elastic', 'paginator.phtml');
?>
<table>
  <thead>
    <tr>
      <th width="25%">Username</th>
      <th width="25%">Role</th>
      <th width="50%">Name</th>
    </tr>
  </thead>
  <tbody>
    <?php
    // Render each item for the current page in a table row
    foreach ($this->paginator as $item)
    {
    ?>
    <tr>
      <td><?php echo $this->escape($item['username']); ?></td>
      <td><?php echo $this->escape(ucfirst($item['role'])); ?></td>
      <td><?php echo $this->escape($item['name']); ?></td>
    </tr>
    <?php
    }
    ?>
  </tbody>
</table>

The script uses the PaginationControl view helper to render the navigator. The view script for the navigator markup is specified as one of the parameters as paginator.phtml; this script is found in the /application/views/scripts directory. The following standard script is used:

<?php if ($this->pageCount): ?>
<div class="paginator">
 
<!-- First page link -->
<?php if (isset($this->previous)): ?>
  <a href="<?php echo $this->url(array('page' => $this->first)); ?>">
    First
  </a> |
<?php else: ?>
  <span class="disabled">First</span> |
<?php endif; ?>
 
<!-- Previous page link -->
<?php if (isset($this->previous)): ?>
  <a href="<?php echo $this->url(array('page' => $this->previous)); ?>">
    < Previous
  </a> |
<?php else: ?>
  <span class="disabled">< Previous</span> |
<?php endif; ?>
 
<!-- Next page link -->
<?php if (isset($this->next)): ?>
  <a href="<?php echo $this->url(array('page' => $this->next)); ?>">
    Next >
  </a> |
<?php else: ?>
  <span class="disabled">Next ></span> |
<?php endif; ?>
 
<!-- Last page link -->
<?php if (isset($this->next)): ?>
  <a href="<?php echo $this->url(array('page' => $this->last)); ?>">
    Last
  </a>
<?php else: ?>
  <span class="disabled">Last</span>
<?php endif; ?>
 
</div>
<?php endif; ?>

The section used to render the current page as a table makes use of the fact that the paginator object can be iterated over to retrieve each item on the current page in turn.

The following styling is applied to the navigator:

.paginator { padding: 5px; }

The following styling is applied to the table:

table { width: 100%; }
 
th, td { padding: 5px; }
 
th { background-color: #4E7DD1; color: #FFFFFF; }

The feed controller is implemented as follows:

class FeedController extends Zend_Controller_Action
{
  public function digestAction()
  {
    try
    {
      $this->_helper->layout->disableLayout();
 
      $id = $this->getRequest()->getParam('id');
 
      if (isset($id))
      {
        $dbBlog = new Default_Model_Db_Blog();
        $blog = $dbBlog->fetchBlog($id);
 
        if (isset($blog))
        {
          $this->view->blog = $blog;
        }
        else
        {
          $this->view->errorMessage = 'Blog ID not found in database';
        }
      }
      else
      {
        $this->view->errorMessage = 'Blog ID not specified';
      }
    }
    catch (Exception $e)
    {
      $this->view->errorMessage = $e->getMessage();
    }
  }
}

The function implementation is wrapped in an exception handler, mainly to catch any database errors. This is the basic use case:

1. As it is not going to render an entire page, but rather respond to an AJAX request, it calls the layout helper to disable layout rendering.
2. It checks the value of the id parameter, which should have been passed via the URL.
3. If the id is set, it retrieves the database record in the blog table for that id.
4. If a blog record is returned, it passes that to the view script.

There are three deviations from this:

1. If the id is not set, it reports an error (‘Blog ID not specified’).
2. If no database record is returned for the specified id, it reports an error (‘Blog ID not found in database’).
3. If an exception is throw, it reports an error; the exact message will depend on the exception.

The implementation of Default_Model_Db_Blog has been covered in previous posts (see the post on the data classes and the post on the mapper classes).

How the blog record and any error messages are handled in the associated view script is the subject of the next post.

The action handler is implemented by the following code:

public function blogsAction()
{
  try
  {
    $dbBlog = new Default_Model_Db_Blog();
    $this->view->blogs = $dbBlog->fetchBlogs();
  }
  catch (Exception $e)
  {
    $this->view->errorMessage = $e->getMessage();
  }
}

There are five classes used to handle access to the database:

• Default_Model_Db_Blog
• Default_Model_Db_Abstract
• Default_Model_Db_Mapper_Blog
• Default_Model_Db_Mapper_Abstract
• Default_Model_Db_Table_Blog

Let us consider Default_Model_Db_Table_Blog first. This class extends Zend_Db_Table_Abstract. The implementation of the class is very simple:

class Default_Model_Db_Table_Blog extends Zend_Db_Table_Abstract
{
  protected $_name = 'blog';
}

Setting the member variable $_name to the name of a table in the database binds the class to that table, and allows it to be used to perform operations against the table. Note that the database connection itself has been set up during the bootstrapping process, as described in the post Bootstrapping the Application: the Standard Database Resource Plugin.

The data in the rows of the blog table is handled by the Default_Model_Db_Blog class; this is linked to the blog table class by a mapper class called Default_Model_Db_Mapper_Blog. Each class contains the code specific to the blog table; they are both derived from an abstract base class which contains the generic code for these type of classes. This allows the easy addition of classes handling other database tables.

In the next couple of posts, we shall look at the implementation of first the data classes, then the mapper classes.

In this next series of posts, I shall look at how the page is implemented. The blog digest is not fetched before the bulk of the page is rendered, as there may be a noticeable delay before it is fetched and therefore before the visitor receives a response. Instead, the page renders each blog tab with a placeholder section, into which the digest feed is loaded using AJAX techniques.

The posts will deal with the following aspects of the implementation:

1. The index/blogs action handler
2. The index/blogs view script
3. The AJAX feed digest helper
4. The feed/digest action handler
5. The feed/digest view script
6. The feed digest helper

As the implementation is complex and is spread over a number of files and classes, I shall be looking at it over the course of several posts. In this post I shall be concentrating on the action handler.

The action handler starts by retrieving the request object:

public function contactAction()
{
  $request = $this->getRequest();

This will be used to determine whether the user has submitted the contact form and what data was submitted.

Then the function creates the form object:

  $form = new Default_Form_Contact();

We shall look at the implementation of this class in a later post.

Then the function determines whether the user has posted the form:

  if ($request->isPost())
  {

If the user has posted the form, the function retrieves the data posted and validates it against the form:

    $post = $request->getPost();
 
    if ($form->isValid($post))
    {

If the data is valid, the function then creates and sends the e-mail.

The first step is to create a Zend_Layout object, then set the layout script and its location:

      try
      {
        $layout = new Zend_Layout();
        $layout->setLayoutPath(APPLICATION_PATH . "/layouts/scripts");
        $layout->setLayout('contact-email');

The Zend_Layout will now look for a file called contact-email.phtml in the application/layouts/scripts directory.

The next step is to create a filter and use it to eliminate any possible HTML injection, before passing the parameters to the layout script:

        $htmlEntities = new Zend_Filter_HtmlEntities();
        $layout->name = $htmlEntities->filter($post['name']);
        $layout->email = $htmlEntities->filter($post['email']);
        $layout->message = $htmlEntities->filter($post['message']);

Then the layout is rendered and stored in a variable:

        $bodyHtml = $layout->render();

The sending of the mail is handled by the Default_Model_Mail_Contact class, which will be examined in a later post. The function creates an object of that class and call its send method, passing the HTML generated above as the parameter:

        $mail = new Default_Model_Mail_Contact();
        $mail->send($bodyHtml);

Then a variable is passed to the view script to flag that the mail has been sent:

        $this->view->sent = true;
      }

Any exceptions thrown during the process of sending the mail are handled in the following catch block:

      catch (Exception $e)
      {
        $this->view->errorMessage = $e->getMessage();
      }
    }

If the form validation fails, the error is passed in a variable to the view script:

    else
    {
      $this->view->error = $form->getFirstFormError();
    }
  }

Finally, the form object is always passed to the view script, to allow it to be rendered if necessary.

  $this->view->form = $form;
}

The layout script for the e-mail is quite simple:

<div>
  <div><strong>Name:</strong> 
<?php echo $this->layout()->name; ?></div>
  <div>
    <strong>E-mail:</strong> 
    <a href="mailto:<?php echo $this->layout()->email; ?>">
<?php echo $this->layout()->email; ?></a>
  </div>
  <div><strong>Message:</strong> 
<?php echo $this->layout()->message; ?></div>
</div>

The fields submitted by the user are injected into the appropriate places in the e-mail.

In the next post, I shall look at the view script for the contact page.