Extending Zend Auth - A Zend Config Adapter

So in the last installment of this series, I provided an introduction to Zend_Auth, Zend_Auth_Adapter_Interface and Zend_Auth_Result and how to implement Zend_Auth_Adapter_Interface to implement a basic test adapter that can be used as a mock object in your testing.

If you missed it, check it out now, then come back and we’ll continue on. If you’ve already read it, then let’s continue now.

As I indicated last time, whilst being a perfectly valid implementation, the Test adapter was rather basic and didn’t do very much. Like all good testing, you need flexibility and options. So in this installment, we’re going to build an adapter based around Zend_Config. This will lead quite nicely in to the last part in the series which uses the wonderful MongoDB as the underlying resource for the adapter.


So in the last installment of this series, I provided an introduction to Zend_Auth, Zend_Auth_Adapter_Interface and Zend_Auth_Result and how to implement Zend_Auth_Adapter_Interface to implement a basic test adapter that can be used as a mock object in your testing.

If you missed it, check it out now, then come back and we’ll continue on. If you’ve already read it, then let’s continue now.

As I indicated last time, whilst being a perfectly valid implementation, the Test adapter was rather basic and didn’t do very much. Like all good testing, you need flexibility and options. So in this installment, we’re going to build an adapter based around Zend_Config. This will lead quite nicely in to the last part in the series which uses the wonderful MongoDB as the underlying resource for the adapter.

A Zend_Config Primer

If you’re not familiar with Zend_Config, the manual states: “…is designed to simplify the access to, and the use of, configuration data within applications”. Just like Zend_Auth, Zend_Db and a host of the other components of the Zend Framework, Zend_Config also allows for the use of a series of config types through config adapters. The ones that are currently implemented are:

  • Ini
  • Xml
  • Json
  • Yaml

So no matter what type of file your configuration information is stored in, if it’s one of these, or can be converted to one of them, you can use Zend_Config quickly and easily to retrieve configuration data for your application.

Given that, it makes it a good choice as the next level in advancement of adapters for us to create. So in this version, we’re going to have a simple Xml file that contains the details of a number of users.

How will it work?

We’re going to create a Zend_Config object from the Xml file, set it as a member variable of our new adapter and then, when the authenticate method is called, we’re going to search in it to see if we have a user with the credentials set in username and password. Not much too it right? Exactly.

Our XML Configuration File

 

<configdata>
    <production>
        <login>
            <users>
	  <settermjd>
                <password>5f4dcc3b5aa765d61d8327deb882cf99</host>
                <firstname>matthew</firstname>
                <lastname>setter</lastname>
            <company>malt blue</company>
                <email>matthew@maltblue.com</email>
	  </settermjd>
	  <citizenj>
                <password>56266a582ccab096b63eceaea36d1f4c</host>
                <firstname>john</firstname>
                <lastname>citizen</lastname>
	    <company>malt blue</company>
                <email>j.citizen@maltblue.com</email>
	  </citizenj>
            </users>
        </login>
    </production>
    <staging extends="production">
        <login>
            <users>
	  <settermjd>
                <password>3c0e32a23e491092f5966071bdeda367</host>
                <firstname>matthew</firstname>
                <lastname>setter</lastname>
	    <company>malt blue</company>
                <email>matthew@maltblue.com</email>
          </settermjd>
            </users>
        </login>
    </staging>
</configdata>

You can see in the xml above, that in production, we have 2 users, settermjd and citizenj. Both of them have the properties: password, firstname, lastname, company and email. Having a look in the staging environment configuration, you can see that only settermjd is there.

Now I’m not that narcissistic, but it shows how we can differentiate between different environments, making testing and development easier. Now on successful login, the information contained in the users details will be set in the identity object and returned in the Zend_Auth_Result object. Arguably nice, clean and efficient.

**NB: **Now what it’s not is likely the way that you would build an adapter for heavy production use, but it does show another way to progress.

The Constructor

public function __construct(Zend_Config $config=null, $username = null, $password = null) { if (!empty($config)) { if (!($config instanceof Zend_Config)) { throw new Zend_Auth_Adapter_Exception(); } $this->_config = $config; } if (!empty($password)) { $this->_password = $password; } if (!empty($username) && ) { $this->_username = $username; } }

This constructor augments the Test adapter constructor and takes a Zend_Config object as its first parameter. The original username and password continue to be used. We then add an extra check to ensure that the object passed in is a valid Zend_Config object before assigning it if it is; the method type hinting should take care of that for us for the most part.

The Authenticate Method

public function authenticate()
{
  if (empty($this->_username) || empty($this->_password)) {
    throw new Zend_Auth_Adapter_Exception();
  }

  // search for the username/password combination in the available list
  $userConfig = $this->_config->users->get($this->_username, null);

  if (is_null($userConfig)) {
    return new Zend_Auth_Result(
      Zend_Auth_Result::FAILURE_IDENTITY_NOT_FOUND,
      array()
  );
} else {
  if (!empty($this->_credentialTreatment)) {
    $credential = $this->_credentialTreatment;
    if (!in_array($credential, $this->_allowedCredentials)) {
      return new Zend_Auth_Result(
        Zend_Auth_Result::FAILURE_UNCATEGORIZED,
	array()
      );
  }
  if ($userConfig->password != $credential($this->_password)) {
    return new Zend_Auth_Result(
      Zend_Auth_Result::FAILURE_CREDENTIAL_INVALID,
      array()
    );
  }
} else {
  if ($userConfig->password != $this->_password) {
    return new Zend_Auth_Result(
      Zend_Auth_Result::FAILURE_CREDENTIAL_INVALID,
      array()
    );
  }
}

return new Zend_Auth_Result(
  Zend_Auth_Result::SUCCESS,
  array(
    'username' => $this->_username,
    'firstName' => $userConfig->firstname,
    'lastName' => $userConfig->lastname,
    'emailAddress' => $userConfig->email,
    'company' => $userConfig->company,
  )
);
}

You can see that the authenticate method is also largely the same. As before, we check if we have a valid username and password. But now, that we also have a valid config object we validate that as well.

Following this, we search in the config object for the user to see if we have one that matches the username passed in. If we found them, we then move to validate the password. As we’re getting more detailed this time, we’ve also lifted a method from Zend_Auth_DbTable; setCredentialTreatment. This allows us to set how we’re going to treat the user credentials – in our case, the password field.

public function setCredentialTreatment($treatment)
{
    $this->_credentialTreatment = $treatment;
    return $this;
}

If it’s not called, then the password is compared as is. If it’s called, then the method that’s set in it is used to compare the password value entered against the value we have stored. You’ll note in the XML config that the password for each user is an MD5 hash. So later on we’re going to call the method, setting md5 as the treatment.

Another point to note is that this is a fairly simple implementation. We’ve added an array **$_allowedCredentials **which restricts the allowed choices of credential functions; specifically to md5 and sha1. We could use call_func_array or something like that to expand this, but well, why take all the fun out of it.

If the user is available and the password matches we then retrieve the details of the user config object and create an identity object with that information and return it as normal.

If the user is not available, then we return the code Zend_Auth_Result::FAILURE_CREDENTIAL_INVALID and an empty identity object. If the password’s don’t match, then we return the code Zend_Auth_Result::FAILURE_IDENTITY_NOT_FOUND and an empty identity object. If the user attempts to set an invalid credential function then we return the code Zend_Auth_Result::FAILURE_UNCATEGORIZED and an empty identity object.

So, what did you think?

  • Too easy, too simplistic?
  • Didn’t go far enough?

I’d love to hear your thoughts where you think this could go and where it could be done better.


You might also be interested in these tutorials too...

Fri, Jun 17, 2011

Extending Zend Auth — The HowTo Series

Zend Auth, if you want to secure a Zend Framework app, along with Zend Acl, it’s essential. But do you know what it is? Do you know how to use it? Do you know how to extend it? Through this series I’m going to show you how to do all three.

Tue, Nov 15, 2011

Rename uploaded files with Zend Framework

Recently I was asked how to rename a file with the Zend Framework that used a Zend Form and Zend File element. They key requirement was that it should not be a hack or a kludged solution. So I thought I’d write a quick post to provide a simple example on how it was achieved.

Wed, Nov 9, 2011

The Zend Framework Bootstrap made simple (Part 3)

Ok, we’ve established that with the Zend Framework, we need to do a bit more work than some of the other frameworks to get up to speed - but that’s not necessarily a bad thing - right?! But it can be a bit tedious and it’s something as professional developers, we want to automate away. So we’ve been addressing in this series how to do just that with a custom, extendable bootstrap class.

In the first part of the series we laid the foundation of our custom bootstrap class by creating a custom class directory structure, adding its namespace to the application ini and modifying the default application bootstrap so that it extends from it and had a look at the first component - caching.

Then, in the second part of the series, we built on the foundation laid in part one by creating plugin resources for the routing table, application navigation and the database connections - these being some of the most common tasks, usually, associated with a web-based application.

In this, the third and final part of the series, I’m going to finish up by looking at application placeholders and surprise, no not logging as originally promised, but pagination. As an added extra, we’re going to be using a key feature of Zend Application to make it a breeze.


Want more tutorials like this?

If so, enter your email address in the field below and click subscribe.

You can unsubscribe at any time by clicking the link in the footer of the emails you'll receive. Here's my privacy policy, if you'd like to know more. I use Mailchimp to send emails. You can learn more about their privacy practices here.

Join the discussion

comments powered by Disqus