Scenario is simple. Your application has three modules and each module needs to be accessible to users with different priviledges:

1. ‘default’ module – accessible to all users and guests
2. ‘member’ module – accessible only to registered users
3. ‘admin’ module – accessible only to registered users with administrator priviledges

I will go step by step and explain all parts in depth:

• database table and model
• registration form
• registration controller action
• login form
• login controller action
• logout controller action
• authentication controller plugin
• recommended reading

Database table and model

Let’s create a database table that will store all users:

CREATE TABLE users (
id INT NOT NULL AUTO_INCREMENT,
first_name VARCHAR(255) NOT NULL,
last_name VARCHAR(255) NOT NULL,
email VARCHAR(255) NOT NULL,
username VARCHAR(255) NOT NULL,
password_hash VARCHAR(255) NOT NULL,
role VARCHAR(255) NOT NULL,
status VARCHAR(255) NOT NULL,
INDEX (first_name),
INDEX (last_name),
INDEX (username),
INDEX (email),
PRIMARY KEY (id)
) ENGINE = INNODB;

The ‘role’ column will hold a user access level, for example: ‘user’, ‘administrator’ etc. The ‘status’ column could have ‘pending’ and ‘approved’ possible values which would allow administrators to approve freshly registered users before they could access private parts of the website.

I put INDEX on ‘first_name’, ‘last_name’, ‘username’ and ‘email’ fields because are often be used instead of the ‘id’ to fetch a single user.

You will also need a model representing the table. Here is a very simple model, in a real-life application you will certainly need more methods (for editing and removing users etc):

Notice this line in the add() method:

What it does is it first prepends the salt to the plain text password and then create an sha1 hash which can be safely stored in the database.

Registration form

Unless you want to create user accounts manually you should allow guests to register. The registration form:

The form is straightforward – a single form element per table column (except ‘id’, ‘role’ and ‘status’). I always use my custom decorators which produce the markup I want.

Registration controller action

First of all, in order to eliminate duplicate rows in the database we check for users with the same username or email before continuing. We also make sure a user correctly filled in both email input fields and both password input fields.

Afterwards, an email with a verification string (which happens to be an sha1 hash of the user email) is sent to the user and a new account is created. I use a handy action helper to generate a random string (in this case used as a salt):

By clicking on the link the user is taken to the email verification page:

Login form

The login form is quite simple. It contains just two input fields (for username and password) and a “Remember me?” checkbox:

Login controller action

Notice this line:

The argument of the setCredentialTreatment() method is probably confusing, it’s a little more complex SQL expression. What it does is it compares the entered password with the password_hash from the database (substitute the entered password for the question mark). CONCAT() is a MySQL function for concating strings (in PHP it’s done with the concatenation operator – ‘.’), SUBSTRING() is very similar to the PHP’s substr() (the only difference is the first character has index 1 in MySQL and 0 in PHP), SHA1() is the same as sha1() in PHP.

Logout controller action

Authentication controller plugin

I always use a controller plugin for authentication. You could possibly do it in controllers (let’s say in the init() method) but I find the controller plugin to be an ideal for this purpose:

As you can see, there are different access rules for each module. It’s not terribly difficult to create more comples access rules. The one thing you must understand is that (quoted from the Zend Framework documentation):

In general, Zend_Acl obeys a given rule if and only if a more specific rule does not apply.

For instance, let’s say you want to disallow logged in users from accessing the login form:

You can also specify actions in the access rules:

One more thing, you need to register the plugin so it works. I usually do it in the bootstrap file:

You need to add the ‘My_’ namespace to the application config file, too:

autoloaderNamespaces[] = "My_"

Recommended reading

• My favorite Zend_Form decorators configuration
• Extending Zend_Form
• Password hashes and salts