A basic version of the class would look something like this:

class Application_Model_Identity
{
  private $_username = '';
  private $_role = '';
  private $_name = '';
 
  public function __construct($resultRow)
  {
    if (isset($resultRow->username))
    {
      $this->_username = $resultRow->username;
 
      if (isset($resultRow->role))
        $this->_role = $resultRow->role;
 
      if (isset($resultRow->name))
        $this->_name = $resultRow->name;
    }
  }
 
  public function getUsername()
  {
    return $this->_username;
  }
 
  public function getRole()
  {
    return $this->_role;
  }
 
  public function getName()
  {
    return $this->_name;
  }
}

This provides an unremarkable means of encapsulating the essential information retrieved via the result row.

As we shall see in a later post, having a role defined for each user is a basic method for providing more finely-grained access control. Typically, a site will allow users to log in at various levels, such as admin.

It is possible to do some more advanced things here.

For instance, in one application I have written, the user can be a member of one or more sales organisations. To support this we have an additional member variable to store these sales organisations:

  private $_salesOrgs = array();

We then extend the signature of the constructor to take the database adapter and logger as additional parameters:

  public function __construct($resultRow, $dbAdapter = null, $log = null)

Then in the constructor, below the lines

      if (isset($resultRow->name))
        $this->_name = $resultRow->name;

we add the following:

      $this->_salesOrgs = array();
 
      if (null !== $dbAdapter)
      {
        try
        {
          // Get the user's sales organisations
          $sql = $dbAdapter->quoteInto(
"SELECT sales_org_id, name FROM sales_org WHERE sales_org_id IN 
(SELECT DISTINCT sales_org_id FROM user_sales_org WHERE username=?)", 
$resultRow->username);
 
          $this->_salesOrgs = $dbAdapter->fetchAssoc($sql);
        }
        catch (Exception $e)
        {
          if (null !== $this->_log)
            $log->err($e->getMessage());
        }
      }
      else
      {
        if (null !== $this->_log)
          $this->_log->crit('Database adapter not specified');
      }

We also add a means to retrieve the sales organisations:

  public function getSalesOrgs()
  {
    return $this->_salesOrgs;
  }

To retrieve the user’s identity, and therefore all the above information, elsewhere in the application, we use the following code:

$auth = Zend_Auth::getInstance();
$identity = $auth->getIdentity();

The class has following methods and member variables:

class Application_Model_Login
{
  private $_dbAdapter = null;
 
  private $_log = null;
 
  public function __construct($dbAdapter = null, $log = null)
  {
    // TODO: Insert construction code here
  }
 
  public function login($username, $password)
  {
    // TODO: Insert login code here
  }
 
  public function logout()
  {
    // TODO: Insert logout code here
  }
}

When using the class, we pass the constructor references to the database adapter and log objects to use; these are stored in the appropriate member variables:

  public function __construct($dbAdapter = null, $log = null)
  {
    $this->_dbAdapter = $dbAdapter;
    $this->_log = $log;
  }

The login method receives the username and password from the calling function:

  public function login($username, $password)
  {

The database adapter must be set, otherwise the class cannot authenticate against the database:

    // Check that the database adapter has been set
    if (null === $this->_dbAdapter)
    {
      if (null !== $this->_log)
        $this->_log->crit('Database adapter not specified');
 
      return false;
    }

Note that the method uses the logger (if it has been supplied) to record this failure. Also, the method returns false to indicate that the login was unsuccessful.

Next, the method gets the date and time of the login attempt; this will be logged later:

    // Get the date and time of the attempt
    $date = new Zend_Date();

Then, the method gets the global authentication object:

    // Get the authentication object
    $auth = Zend_Auth::getInstance();

Next, the method creates an authentication adapter:

    // Set up the authentication adapter
    $authAdapter = new Zend_Auth_Adapter_DbTable(
      $this->_dbAdapter, 'user', 'username', 'password', 'md5(?)');
    $authAdapter->setIdentity($username);
    $authAdapter->setCredential($password);

The adapter is passed the username and password supplied to the method. In this case, the database is assumed to have a user table, with fields named username and password. Also, the password has been encrypted using MD5.

The method is now ready to authenticate the user, using the global authentication object and the adapter:

    // Attempt to authenticate the user
    $result = $auth->authenticate($authAdapter);

If the attempt is successful, the method now gets the entire row in the database table associated with the user. This information is used to create the identity object. This object is an instance of the class Application_Model_Identity, which we will examine in a subsequent post. This identity is stored in the global authentication object. The application will be able to determine whether the user is logged in by the existance of the identity.

   // Check the result of the attempt
    if ($result->isValid())
    {
      // Get the result row object
      $resultRow = $authAdapter->getResultRowObject();
 
      // Create the identity object
      $identity = new Application_Model_Identity($resultRow, 
$this->_dbAdapter, $this->_log);
 
      // Store it in the current session
      $auth->getStorage()->write($identity);

The method uses the logger (if it has been supplied) to record this success, including the date of the attempt:

      if (null !== $this->_log)
      {
        // Log the successful login
        $notice = sprintf('Successful login from %s by %s at %s',
          $_SERVER['REMOTE_ADDR'], $username, $date->toString());
        $this->_log->notice($notice);
      }

Finally, the method returns true, to indicate that the login succeded:

      return true;
    }

If the login attempt fails, the method uses the logger (if it has been supplied) to record this failure, including the date of the attempt:

    else
    {
      if (null !== $this->_log)
      {
        // Log the failed login attempt
        $warn = sprintf(
          'Failed login attempt (invalid username/password) from %s by %s at %s',
          $_SERVER['REMOTE_ADDR'], $username, $date->toString());
        $this->_log->warn($warn);
      }

It then returns false, to indicate that the login failed:

      return false;
    }
  }

The logout function is quite simple. We get the authentication object, then clear any identity stored in it:

  public function logout()
  {
    // Get the authentication object
    $auth = Zend_Auth::getInstance();
 
    // Clear the user identity to log out
    $auth->clearIdentity();
  }

The application will now regard the user as being logged out.

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

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[] =