Chris Morrell

In most of my applications I like to handle authorization (querying the ACL) in one (or more) of three ways:

• Authorize access to a model’s method
• Authorize access to a controller action
• Authorize access to an arbitrary “permission”

In general I find it’s best to keep authorization within the domain (querying the ACL within my models when they’re accessed) as this provides the most consistent behavior.  For example, if I eventually add a REST API to my application I don’t have to duplicate all my authorization logic in the new REST controllers.  When the application calls something like Default_Model_Post::save() it either saves or throws an ACL exception, no matter where it was called from.  This is great in that it saves me from having to duplicate code and keeps my system more secure.

On the other hand, there are times when it’s just a lot easier to handle authorization in the controller.  For example, if guests should never access my “Admin” module, it doesn’t make sense to ever let them access /admin/ URLs.  Also, if you’re using Zend_Navigation, having ACL resources that match controller actions lets you utilize its ACL integration.

If you’re ever going to mix these two techniques, you’ll eventually bump into the case where a model and a controller share the same name.  What if you need to set permissions on a “user” controller and different permissions on a “user” model?  This is where namespacing comes into play.  As suggested by the Zend Framework manual, I always name my controller action resources in the format mvc:module.controller.action.  I name my model resources similarly, in the format model:module.modelName.methodName.  In both theses cases, “mvc” and “model” are the namespace, and everything following the colon is the actual resource name.  Now I can refer to my “admin” module as mvc:admin and the models within my admin module as model:admin.

This is where things get interesting.  If you set up your ACL chains correctly, you can set permissions on whole modules or models and have those rules cascade to their child controllers or methods.  For example, say you set up your ACL as follows:

$acl = new Zend_Acl();
$acl->addResource('mvc:');
$acl->addResource('mvc:admin', 'mvc:');
$acl->addResource('mvc:admin.user', 'mvc:admin');
$acl->addResource('mvc:admin.user.create', 'mvc:admin.user');

$acl->addRole('guest');
$acl->addRole('admin', 'guest');

$acl->deny();
$acl->allow('admin', 'mvc:admin');

Now if a user with the role “admin” tries to access the resource “mvc:admin.user.create” (http://basename/admin/user/create) they will be allowed, but a user with the role “guest” will not.  Using this technique gives you as much granularity as you need in your ACL, but at the same time lets you set broad permissions where appropriate.

This is where Galahad_Acl comes into play.  Setting up all these resources can be tedious, as is checking permissions in each controller.  Galahad_Acl in conjunction with Galahad_Model_Entity and Galahad_Controller_Plugin_Acl automate everything but the actual permissions that are specific to your application.

Continue reading “Namespacing ACL resources & Galahad_Acl” »

For the last couple of months I’ve been incorporating portions of applications I’m working on into my Galahad Framework Extension project.  Right now it’s not at a point where I’d feel comfortable promoting it (you can check out the project on GitHub if you want), but there are portions that are pretty solid that might be useful to others right now.  Two such portions are Galahad_Validate_Uri and Galahad_Filter_PrependHttp which are both very useful for processing forms with URL fields.

Continue reading “Zend Framework URI validator & filter” »

[Updated with follow-up video]

About a month ago I posted some ideas about PHP modeling in the Zend Framework and requested feedback. After a month of on-and-off discussions through this website and #zftalk I decided to sit down and implement things a little more.
Continue reading “More PHP Modeling (w/ video demo)” »

This just came up on #zftalk, and it appears that the information out there is either incomplete or incorrect, so I thought I’d just put out a simple solution.  Here’s a simple way to calculate the difference between two Zend_Date objects (in days):

$jan1 = new Zend_Date('1.12.2009', Zend_Date::DATES);
echo "\nJanuary first: ", $jan1->toString();

$christmas = new Zend_Date('25.12.2009', Zend_Date::DATES);
echo "\nChristmas is on: ", $christmas->toString();

$diff = $christmas->sub($jan1);
echo "\nNumber of days: ", $diff / 60 / 60 / 24;

I’ve been thinking a lot about Modeling in a MVC application, particularly in the Zend Framework. Obviously each application is different, and any Model is going to be fairly unique to your application. That’s why ZF doesn’t provide a base Model class. That said, there are some design patterns that a lot of people are using nowadays, and applications could use some base functionality to facilitate those patterns.

Zend Framework’s project lead, Matthew Weier O’Phinney, has a lot of great thoughts about Modeling that I’ve been trying to stick to. In implementing those ideas, I’ve started thinking out some base classes to build my Models on top of. Obviously these classes won’t work for everyone. But they should work for a lot of “typical” web applications.

Continue reading “PHP Modeling (in Zend Framework)” »

Someone was recently asking on ZFTalk about how to use a different layout for each module in your application. Since this is a problem I’ve dealt with in the past and planned on adding to the Galahad FE, I thought I’d quickly write up a tutorial on how to do it:

First, download the Plugin

Put the following class in a library/Galahad/Controller/Plugin/Modularlayout.php file (you’ll probably have to create all those directories and the file).

<?php
/**
* This file is part of the Galahad Framework Extension.
*
* The Galahad Framework Extension is free software: you can redistribute
* it and/or modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation, either version 3 of the
* License, or (at your option) any later version.
*
* The Galahad Framework Extension is distributed in the hope that it will
* be useful, but WITHOUT ANY WARRANTY; without even the implied warranty
* of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
* General Public License for more details.
*
* @category  Galahad
* @package   Galahad
* @copyright Copyright (c) 2009 Chris Morrell <http://cmorrell.com>
* @license   GPL <http://www.gnu.org/licenses/>
* @version   0.2
*/

/**
* Use separate layout per module
*
* @category   Galahad
* @package    Galahad
* @copyright  Copyright (c) 2009 Chris Morrell <http://cmorrell.com>
* @license    GPL <http://www.gnu.org/licenses/>
*/
class Galahad_Controller_Plugin_Modularlayout extends Zend_Controller_Plugin_Abstract
{
     public function routeShutdown(Zend_Controller_Request_Abstract $request)
     {
          Zend_Layout::getMvcInstance()->setLayout($request->getModuleName());
     }
}

Next, add the Galahad namespace

Update your Bootstrap.php file’s autoloader initialization method (if you don’t have one, add one):

protected function _initAutoloaders()
{
	$this->getApplication()->setAutoloaderNamespaces(array('Galahad_'));
	return $this;
}

Please note: You might need to have other namespaces in there, like My_ or App_ or Default_.

Next, add the Plugin

Update your Bootstrap.php file’s plugin initialization method (if you don’t have one, add one):

protected function _initPlugins()
{
	$this->bootstrap('autoloaders');
	$this->bootstrap('frontController');

	$plugin = new Galahad_Controller_Plugin_Modularlayout();
        $this->frontController->registerPlugin($plugin);
}

And you’re set!

Just make sure you have a layout file in your layouts directory for each module (modulename.phtml).