It makes sense that initialization, filtering the page content, and adding administrative features are at the top of the list.  It’ll be more interesting to see whats a little further down.  I’ll post more as I have time to make sense of the data.

When Safari 5 came out I decided to make the switch.  The new Safari developer tools rival Firebug, Safari now supports extensions, and Firefox has been causing all sorts of problems for me lately (20-second freezes, choppy video, etc).  There were three things that I knew I couldn’t live without…

Those were:

• AdBlock
• Delicious.com Integration
• The Zend Studio Toolbar

The first two were ported to Safari within days (if not hours) of the Safari 5 release.  The third is likely to take a while, so I decided to put together my own version for the time-being.  Right now it’s very much in an “alpha” stage.  It only supports the “debug current page” command, and it hasn’t been tested all that thoroughly.  That said, I plan on developing this over the next few weeks to mirror most of the features available in the current Zend Studio Toolbar for Firefox and MSIE.

I’m also adding some features of my own.  Namely, the toolbar remembers what domains you’ve enabled debugging on, and only shows itself on those domains.  There’s a browser button that you can use to toggle debugging, and in the future I want to add an indicator when the page you’re on supports debugging.

If you develop with Zend Studio and Safari, please check out the current version of the extension.  I could really use some feedback from other folks (particularly those who have other workflows from me).

Wouldn’t it be nice if you’d had something like this:

Well, there are two things you can do.  The first is to vote on ZF-9509 and ZF-9508.  But until the documentation is fixed, you can download my Greasemonkey script that gives you a page TOC right now:

[Download id not defined]

Hope you enjoy!

• Create /path/to/vhosts/projectname/public
• Edit /etc/hosts to add 127.0.0.1 projectname.localhost
• Edit /path/to/httpd-vhosts.conf to add a new <VirtualHost> directive for projectname.localhost
• Repeat for each new project

It’s not a big deal—maybe a two minute distraction—but it always bugged me.  I’d looked into automating this before, but it always led to me installing a DNS server on my local machine, which is something I don’t particularly want to do.  Then, just a few days ago, I accidentally stumbled on to a fantastic cross-platform solution.

First let’s start with Apache, which was always the un-problematic part of the equation.  There’s a great Apache extension called mod_vhost_alias that was made to do just this.  All you need is one slightly modified <VirtualHost> directive and you’re set:

<VirtualHost *:80>
    ServerAdmin webmaster@localhost
    VirtualDocumentRoot "/path/to/vhosts/%1/public"
    ServerName subdomains.localhost
    ServerAlias *.localhost
    LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon
    ErrorLog "logs/vhosts-error_log"
    CustomLog "logs/vhosts-access_log" vcommon
</VirtualHost>

And you’re also going to want to set directory permissions on all those directories:

<Directory "/path/to/vhosts/*/public">
    Options Indexes FollowSymLinks
    AllowOverride All
    Order allow,deny
    Allow from all
</Directory>

You’ll also probably want to turn UseCanonicalName Off.  Now Apache is set up to map anything.localhost to /path/to/vhosts/anything/public.  The problem is, your computer still doesn’t know that it should be handling http://anything.localhost.  That’s where the proxy auto-config file comes into play.

Proxy Auto-Config files, or PAC files, were designed to help your browser determine if and when it should use a proxy.  PAC files are actually just simple JavaScript files with one function that takes URL and Host Name arguments and returns a string telling the browser what to do.  Often this would be used to send certain traffic through a proxy, or proxy certain traffic at certain times of the week (it might be useful as a distraction-blocker as well), but in our case we’re going to use it to forward all .localhost traffic back to our local web server.

Just create a file called localhost.pac and put the following inside it:

function FindProxyForURL(url, host)
{
	if (dnsDomainIs(host, ".localhost")) {
		return "PROXY localhost";
	}

	return "DIRECT";
}

Basically what this file is saying is, if the domain is *.localhost, send it to localhost, otherwise just connect directly.  All you have to do is save that file and tell your browsers to use it, and you’re set.  Each browser is a little different, but most (if not all) support PAC files:

• Safari: System Preferences -> Network -> Advanced… -> Proxies -> Automatic Proxy Configuration
• Firefox: Preferences -> Advanced -> Network -> “Configure how Firefox connects to the Internet” -> Automatic proxy configuration URL
• MSIE: Tools -> Internet Options -> Connections -> LAN Settings -> Use automatic configuration script
• Chrome: Uses Safari/Internet Explorer settings
• Opera: Preferences -> Advanced -> Network -> Use automatic proxy configuration

Now, when you go to http://mynextawesomeidea.localhost your system will automatically attempt to load /path/to/vhosts/mynextawesomeidea/public.  Any time you want to start a new project, just create the directory and go!

A couple notes: this technique messes with a few environmental variables.  Apache seems to get confused about your DOCUMENT_ROOT and REQUEST_URI.  Your document root is going to be your global document root, not the /path/to/vhosts/… directory, and your REQUEST_URI will include the hostname and protocol parts, not just the path and query parts.  Another side effect is that you need to set your RewriteBase to / if you’re using mode_rewrite.

The book is structured in two parts.  The first two chapters cover the basic setup of the Zend Framework (ZF) and, more specifically, a look at its Model-View-Controller (MVC) implementation.  Almost all of the book from there on out focuses on building a real-world ecommerce application using ZF.  I tend to be a learning-by-doing type of person, which I think tends to be true of many programmers, so I think this is a pretty good way to lay out a book.

Much of the book focuses on Models, and how to use various ZF components to implement your domain logic.  Most people agree nowadays that you should have fat models and skinny controllers (in that your controllers should really just have enough code to facilitate your models doing the work), and Keith Pope’s focus on models really hits this home in the book.  The topics of user accounts, the shopping cart and the catalog are all addressed in this light, while still bringing up topics like forms, controllers, views, action helpers, etc.

In general, the book focuses on best practices, which I think is really important for new ZF developers.  Because one of the guiding principals of the Zend Framework is that it gives you freedom to implement things however you like and use only the components you want, it can be hard for people just getting started to get a sense of how they should use certain components, and particularly how everything falls together in a “typical” MVC application.   Following along with the development of the storefront application in this book is a great way to see how those components often are used together.

That said, there are ways in which the code in this book is outdated or less-than-ideal.  As with anything that moves as fast as the Zend Framework has been moving, it’s hard to keep up with the latest tricks and best practices (and in some places it feels like they skipped on editing to try to publish the book before it got too outdated—there are plenty of minor code inconsistencies and typos throughout).  This book is a good place to get started, but keep in mind that the Zend Framework is already at 1.10, with 2.0 on the horizon, so anything that’s not the Zend Framework Official Documentation is in danger of being out of date at any moment.

Also, keep in mind that there’s already a lot of good information out there, so if you don’t mind finding it yourself, you might not need a book.  In fact, I found that most of the code in the authorization chapter was almost a direct copy of Matthew Weier O’Phinney’s blog post on Applying ACL’s to Models.  If you read blogs like Matthew’s (who is the project lead for ZF, and a fantastic resource) and spend time on #zftalk you can figure most things out on your own (Ben Scholzen’s demo application is another good starting point).  The information may be a little scattered, but it’s out there.

In the end, I think that this book would be a really helpful resource to someone who’s just getting started with MVC architecture and other design patterns in PHP.  It also is a good way to see most of the Zend Framework best practices put to use in one place.  On the other hand, if you want the latest information available and are willing to work for it, everything you need is probably online and free.

Some resources that might be helpful to new ZF developers:

• Zend DevZone
• Questions tagged w/ Zend Framework on Stack Overflow
• #zftalk
• Zend Framework in Action Blog
• Matthew Weier O’Phinney’s Blog
• Ryan Mauger’s Blog
• Ben Scholzen’s Blog

source path/to/zf.bash

Next time you load the terminal, you can type “zf c” and hit TAB twice to see a list of available commands (change, configure and create” or type “zf cr” and hit TAB to have “create” automatically inserted for you.  The script works for both action names and provider names (but not for anything past that).  Eventually I want the script to dynamically load the available commands (so that it works with custom providers and future versions of ZF without updates) but I couldn’t get that working for this version so I just hard coded them.

There’s also a version that completes commands from the Galahad Framework Extension if you’re testing that out…

Enjoy!

• 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.

By default, whenever Galahad_Acl has a role added to it in the format “namespace:resource.subResourse” (etc) it automatically adds the resources up the chain.  For example, if I add “mvc:default.index.index” to a Galahad_Acl object, it would add the following resources to the ACL:

• mvc:
• mvc:default (parent = “mvc:”)
• mvc:default.index (parent = “mvc:default”)
• mvc:default.index.index (parent = “mvc:default.index”)

Galahad_Controller_Plugin_Acl takes this a step further by automatically adding any controller action that’s dispatched to the ACL and then checking against the ACL.  This means that with the following ACL:

$acl = new Galahad_Acl();
$acl->addRole('guest');
$acl->addRole('staff', 'guest');
$acl->addRole('admin', 'staff');
$acl->addResource('mvc:blog.entry.view');
$acl->deny();
$acl->allow('admin', 'mvc:');
$acl->allow('staff', 'mvc:blog');
$acl->allow('guest', 'mvc:blog.entry.view');

The following would be true:

• Role “admin” would be allowed access to any URL (“admin” is allowed access to “mvc:”)
• Role “staff” would be allowed access to /blog/entry/edit even though permissions weren’t explicitly set for the resource “mvc:blog.entry.edit” (because “staff” is allowed to access “mvc:blog”)
• Role “guest” would be allowed to view /blog/entry/view but no other portion of the blog (“guest” is allowed access to the specific resource “mvc:blog.entry.view”)

Galahad_Model_Entity works similarly.  By default each entity adds itself to the ACL in the format “model:module.modelName” so that the model Default_Model_User has the resource ID “model:default.user”.  Each model has a method called _initAcl which lets you manage permissions on a per-model basis.  This is better demonstrated in code:

class Default_Model_Post extends Galahad_Model_Entity
{
    protected function _initAcl($acl)
    {
        // Deny permissions to anything on this model unless explicitly allowed
        // We don't have to add "model:default.post" because Galahad_Model_Entity
        // automatically does that for us
        $acl->deny(null, $this);

        // Allow guests to fetch the content of posts
        $acl->allow('guest', $this, 'fetch')

        // Allow admins to save changes to posts
        $acl->allow('admin', $this, 'save')
    }

    public function save()
    {
        if (!$this->getAcl()->isAllowed($this->getRole(), $this, 'save')) {
            throw new Galahad_Acl_Exception('Current user is not allowed to save posts');
        }

        $dataMapper = $this->getDataMapper();
        return $dataMapper->save($this);
    }
}

So, as you can see, the model denies access to itself unless explicitly allowed, and then allows access to certain methods for certain roles.

All three of these classes are in their early stages of development, but I’d love some feedback on the ideas/suggestions on how to make them better.

Check out the code on GitHub:

• Galahad_Acl
• Galahad_Controller_Plugin_Acl
• Galahad_Model_Entity

Also, for more information about the Galahad_Model system, check out my previous post on modeling in the Zend Framework.

Recently I was building a form that contained a URL field, and after browsing the Zend_Validate docs, I was surprised not to find a Zend_Validate_Uri component.  Luckily, Zend_Uri already validates URIs, so it was just a matter of writing a wrapper that followed the Zend_Validate APIs.  Basic usage:

$validator = new Galahad_Validate_Uri();
$validator->isValid('http://www.google.com/');

Obviously this would be much more useful when combined with Zend_Form or some more extensive validation chains, but you get the point.

Grab Galahad_Validate_Uri from GitHub.

The second issue I often deal with is people forgetting (or not knowing) to include http:// in the URLs that they submit.  Rather than solve this at the controller-level, I decided this was a common enough problem to build a Zend_Filter component for.  Basic usage:

$filter = new Galahad_Filter_PrependHttp(array(
    'allowedSchemes' => array('http://', 'https://', 'mailto:'),
    'checkUri' => true,
));
echo $filter->filter('google.com'); // Prints 'http://google.com'

This filter takes any string and prepends “http://” to it if it doesn’t already contain an allowed scheme (more on that below).  By default it allows “http://”, “https://” and “mailto:” schemes, but you could set this to anything (say you want to allow “itms://” [iTunes] links) by setting the ‘allowedSchemes’ option.  It also (optionally) checks if the resulting URI is valid, and only applies the filter if it is (effectively only prepending “http://” to otherwise valid URIs).  Remember, though, that “http://something” is technically a valid URI, so that will be accepted.  In the future I hope to add additional options to limit to URLs that follow certain standards.

Grab Galahad_Filter_PrependHttp from GitHub.

Update: I’ve submitted Zend_Filter_PrependHttp to the Zend Framework wiki for comments.  Check it out and let me know if you think there’s anything I should change (I’ve posted a few ideas already).

The validator and filter work well together with Zend_Form to create URL form elements:

$this->addElement('text', 'my_url', array(
    'label' => 'URL:',
    'filters' => array('StringTrim', 'StringToLower', new Galahad_Filter_PrependHttp()),
    'validators' => array(new Galahad_Validate_Uri()),
));

The form element generated by that code will produce fairly normalized, valid URIs.

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.

I now have some working base classes that can be found on GitHub. Right now I’m still thinking things out, so there’s no guarantee that’s the structure I’m going to finish with, but it’s what I’m playing with right now. So far I’ve dropped the DAO interface and the Galahad_Service parent class all together (since both are going to be pretty unique to your application). What’s left is mostly the Entity class and the DataMapper class (as well as a very generic Collection class).

I’ve also started to write some tooling for my modeling system, based on Zend_Tool. Right now it’s generating the model itself, a DAO based on Zend_Db_Table and a Zend_Form (see Matthew Weier O’Phinney’s post about using forms in your models for my reasoning there). It doesn’t generate the DataMapper yet, but that’s just a matter of writing the code…

Again, I’d love some feedback on the direction this is going. Check out the video below and then let me know. Comment below, email me at *****@cmorrell.com or get in touch on Twitter: @inxilpro.

[View full size, or watch below]

Follow-up Video (demo of a lot more code):

identity = base64(encrypt_rijndael256([
	sha512_hmac(username, appUsernameSecret),
	sha512_hmac(password, appPasswordSecret)
], appSecret))

This would produce an base64 representation of an encrypted array of hashes.  Basically, the system would produce two hashes using HMAC and two separate secret keys (one for the username hash and one for the password hash).  It would store that data in a way that it could later retrieve it (in my case a serialized array) and then encrypt the whole thing with a third key (the base64 is just so it could easily be represented by an ASCII string).  That way there are multiple points of failure.  An attacker would have to know all three keys just to get at the hashes, but then that’s all they’d have.  They’d still need to brute force both the username and password separately.  It seems to me that this would be pretty darn secure.  Clearly not good enough for a bank, but certainly fine for a web app that would have very few negative consequences if it were broken into.

I would love feedback from someone who know’s what they’re talking about   Below is some working PHP code to illustrate my point:

class PublicAuth
{
    private $_secret;
    private $_usernameSecret;
    private $_passwordSecret;

    private $_td = null;
    private $_iv = null;

    public function __construct($secret, $usernameSecret, $passwordSecret)
    {
        $this->_secret = $secret;
        $this->_usernameSecret = $usernameSecret;
        $this->_passwordSecret = $passwordSecret;
    }

    public function generateIdentifier($username, $password, $algorithm = 'sha512')
    {
        return $this->_encrypt(serialize(array(
            hash_hmac($algorithm, $username, $this->_usernameSecret, true),
            hash_hmac($algorithm, $password, $this->_passwordSecret, true),
        )));
    }

    public function verifyIdentity($identifier, $username, $password, $algorithm = 'sha512')
    {
        $identifier = unserialize($this->_decrypt($identifier));
        return (hash_hmac($algorithm, $username, $this->_usernameSecret, true) == $identifier[0]
            && hash_hmac($algorithm, $password, $this->_passwordSecret, true) == $identifier[1]);
    }

    private function _encrypt($string)
    {
        $this->_initMcrypt();
        return base64_encode(mcrypt_generic($this->_td, $string));
    }

    private function _decrypt($string)
    {
        $this->_initMcrypt();
        return mdecrypt_generic($this->_td, base64_decode($string));
    }

    private function _initMcrypt($algorithm = 'rijndael-256')
    {
        if (null == $this->_td || null == $this->_iv) {
            $this->_td = mcrypt_module_open($algorithm, '', 'ecb', '');
            $this->_iv = mcrypt_create_iv(mcrypt_enc_get_iv_size($this->_td), MCRYPT_RAND);
        }

        mcrypt_generic_init($this->_td, $this->_secret, $this->_iv);
    }
}

And here’s some sample usage:

$pa = new PublicAuth('a', 'b', 'c');
echo $pa->generateIdentifier('user', 'pass');

Which would print out:

NLgAYjlGbmJA2Wdcgwntm4ixhHHCiZBA6TvgrVMgEOBEjZQJ0tHgAlw7931p2S6KRtfCkLjrsA2DBilcgBX/pPPXFgyAx3g0/CKMcjdU8DKn3/9M2aIZHOrdi/G68C0oxVe6pDlWvVwvofpJnu9RxMbFN49x1uVgBuHTjKagpD6y83fm+hX4G+CoPRcHM5PUq/nJ1iwtZipRtno8TllO6A==

Then to verify the identity:

$pa = new PublicAuth('a', 'b', 'c'); // Needs to be the same as when generated
var_export($pa->verifyIdentity($id, 'user', 'pass')); // $id contains the string above; returns TRUE

Thoughts?