Zend_Acl is a very powerful tool to help manage access control logic, but it can be a bit difficult to determine exactly where and how to use it.
In previous Zend Framework apps I’ve written, I often handled access control at the level of the controller action. Each action was represented in the ACL as a resource, and the ACL logic was applied by a custom plugin just prior to any action dispatch.
This is a common enough solution, but I’m not sure it’s always the best one. The thing is, an “action” doesn’t really sound like a “resource” …it’s not a thing you need, it’s a thing you do. Doing access control in the controller layer is also kind of fragile; all you’re really restricting is the user interface, even though what you want to restrict is the application itself: the data and its business.
Access control in the model layer
As a result of these concerns, I decided on a lower-level, model-centric approach for this blog: my models are my resources. Each model class implements Zend_Acl_Resource_Interface, and the ACL specifies “create,” “read,” “update” and “destroy” privileges for each class (more or less). This is a nice paradigm, because it allows for access control at a much lower level: instead of restricting access to the user interface (the controller layer), we restrict access to the business logic (the model layer). (It also makes dynamic assertions a lot more useful, for reasons I may explain some other time.)
In code, checking privileges is as simple as this:
1 2 3 4 5
Posting the guard: record listeners
However, doing this manually can get a bit tedious, and is a particularly big problem if you’re aiming for a thin, lightweight controller layer. Ideally, we’d want these access control checks to happen automatically; fortunately, Doctrine has provided a way with its record listeners. Doctrine_Record_Listener is to Doctrine_Record what Zend_Controller_Plugin is to Zend_Controller_Action: it specifies a set of pre- and post-operation hooks in which you can extend the underlying framework’s base behavior.
For example, since I know that I never want a record inserted into the database if the current user doesn’t have “create” privileges for that model, I can do something along these lines:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Implement the same types of checks on preUpdate() and preDelete(), and you’ve got yourself a working record listener. All that’s left at that point is to register it with Doctrine at the appropriate level. You can take care of it easily enough at the manager level, like so:
1 2 3 4 5
However, if you specify any other listeners at the connection or table level (which is especially true if your model has any “actAs” behaviors), your manager-level listeners will be overridden (see DC-248 on the Doctrine issue tracker for more information). As a result, if you’re going to be using behaviors on your model, you’ll need to add the listener explicitly to each of your tables, like so:
1 2 3 4
But what about reads?
So far so good, but we haven’t done anything for the “read” privilege yet. As it happens, “read” operations need to be treated a bit differently. There are two situations in which read operations might take place:
- Fetching a single record from the database (e.g.,
- Fetching a collection of records from the database (e.g.,
Now, if we were to throw our usual Blahg_Model_Exception_Forbidden whenever an impermissible record was retrieved, case #1 would work just as expected; the user wouldn’t get to see the record. However, in case #2, things are more problematic; we don’t want to halt the entire operation just because of a single impermissible record—after all, the user might still have legitimate access to other records in the collection.
Instead, we’re going to make Doctrine behave as though impermissible records don’t exist—any impermissible records should simply be removed from the return values of any method that returns records.
There currently isn’t a listener method available that allows for the modification of a result set (see DC-280); however, Doctrine 1.2 allows you to write your own hydrator classes, which with a little ingenuity can handle this kind of logic easily enough. Take a look:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Once you’ve got this put together, you’ll need to register the new hydrator with Doctrine_Manager, like so:
…and then remember to use it whenever you retrieve records (there may be a way to set it as the default, but I haven’t found it yet):
I commented on a few of the downsides of this approach in DC-280, but until some of those issues can be remedied, I think it’s a pretty effective solution. Hopefully this post helps someone who’s trying to do the same thing.