• 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, 'model:default.post');

        // Add additional resources (class methods)
        $acl->addResource('model:default.post.fetch');
        $acl->addResource('model:default.post.save');

        // Allow guests to fetch the content of posts
        $acl->allow('guest', 'model:default.post.fetch')

        // Allow admins to save changes to posts
        $acl->allow('admin', 'model:default.post.save')
    }

    public function save()
    {
        if (!$this->getAcl()->isAllowed($this->getRole(), 'model:default.post.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.

To whom it may concern:

My company was considering using livestream as a live streaming provider for our educational content.  This new initiative has convinced me to look elsewhere, as it has been my experience that anti-piracy measures only hurt consumers and small businesses.  It may be true that these measures protect very large (and outmoded) copyright holders, but at the same time they hamper innovation and limit consumer access to content.  We would rather partner with a company that devotes 100% of its resources to providing the best service possible.

Regards,

Chris Morrell

Sure, piracy is a real issue.  As a content producer I certainly understand the desire to stop people from stealing stuff I worked really hard to make.  But I think anti-piracy is a much bigger issue.  DRM and its cohorts have made it impossible for me to consume content I own a few too many times for me to support a company that has declared that it’s making anti-piracy a top concern.

I want to say thanks to everyone who came out to the event! Also thanks to Joe Kaufman and Rob Hall for their fantastic presentations. We ran a little long and some folks had to leave before seeing Joe’s demo, so I just wanted to mention it here. For those of you who haven’t see it, GameSalad is pretty magical, and the demo definitely got more than one round of applause. Check it out (take a minute or two to watch the demo video—you’ll be blown away). You should also check out Rob’s PhillyGeekCentral app (written entirely in ActionScript 3 and compiled using Flash CS5).

Beyond that I just wanted to open up the comments for any feedback anyone might have on my talk, and to answer any questions that came up after we finished with Q&A. Feedback is particularly useful to me (and don’t be afraid to criticize—I can handle it) because I haven’t done much presenting and am still trying to get a sense for what works and what doesn’t.

There are two things that came up in private after the presentation that I think are worth sharing with everyone:

1. A couple people asked me about styling applications written for PhoneGap or Titanium. In the case of PhoneGap you don’t really get any built-in styles because it’s really just a web page running in a chrome-less browser. That means if you want to mimic the iPhone’s UI or create something similar, you have to do it all with CSS and JavaScript. Luckily there are a number of frameworks out there that do that for you, and when I get my slides online I’ll have a bunch of resources to start with. For right now I would recommend checking out XUI and jQTouch. These tools help you get a nice mobile UI up and running in no time. (It’s worth mentioning that in the case of Titanium this is less of an issue because you can use native components.)
2. I also noticed that the question of local storage came up a few times, and I just wanted to clarify there. Mobile Web Apps, PhoneGap Apps and Titanium Apps all have access to local storage. Even in a web app, you can save settings to the phone that will still be there when the user closes Mobile Safari and reopens it. You don’t have to talk to a web server at all if you don’t want to.

Finally, I wanted to talk a little about choosing whether you should build a web app or a native app. This is something I’ve been thinking about a lot and just didn’t have time to talk about last night. Right now everyone is trying to get on Apple’s App Store. It seems like most major web sites either have native apps on the store already, or are planning to do so soon. But in the case of services that aren’t used daily (or at least weekly) I don’t think this makes any sense. There’s a reason that Kayak.com (thanks to Andy Mroczkowski for this perfect example) is a web site and not a program that you download for your computer; For services that you only use time-to-time, it doesn’t make any sense to use a dedicated application. So why would you want a dedicated application on your phone? Well, you probably don’t. But because everyone needs to be on the App Store today, that’s where you’ll find Kayak’s best mobile interactions.

That’s not to say that there aren’t a ton of instances where a native app wouldn’t be worth it. I just think that far too many people are trying to develop native apps when they really aught to be working on great mobile web sites (or web apps). Just like anything else, think about your users and their needs and choose the best option for them, even if it’s not 100% buzzword friendly.

Well, this post came out a lot longer than anticipated. If you can’t tell, mobile development is a topic that I’m happy to talk about, so if you have question feel free to ask.

Here are some of the resources I mentioned for mobile app development:

• Safari Mobile Web Programming
• Viewport Meta Element
• CSS3 Media Queries
• PhoneGap
• Titanium Mobile
• Apple iPhone Dev Center
• W3C Geolocation API
• Offline Storage & Caching
• CSS3 Transitions

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?

$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;

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.

That said, here are some notes that I’ve been putting together. I’m posting them now (very early) in hopes that I get some feedback.

The 6 Classes

Galahad_Model

This is the base class that all my others extend. It is there mostly to provide some helper functionality that all my other classes use (mostly for guessing class names based on a naming convention—more on that later).

Galahad_Model_Entity

The Entity is the base for all things. For example, a User would extend the Entity class. The Galahad_Model_Entity class has some basic methods for getting other objects. I haven’t thought this entirely through yet, but an example would be the Entity’s “Parent” Service (see below) or maybe a Form associated with that model or something similar.

Galahad_Model_Collection

The Collection class is just a wrapper for an array of Entities. I like this because it allows for type hinting/etc. This is pretty much a generic wrapper for an array that implements Iterator and Countable. I can’t think of much more that it needs.

Galahad_Model_Service

This probably doesn’t belong as part of the “Model”—I need to think that out. The Service Layer is where your application logic happens that’s not strictly part of a particular Model (for example, an interaction between two Models). An example might be authentication. The service layer will often map pretty closely to a public API (although obviously there will be things that your application can do that shouldn’t be exposed to the public).

Galahad_Model_DataMapper

The DataMapper maps your Entity to the appropriate DAO (see below) and makes sure the DAO gets the data it’s expecting. The way I think about this is that the Data Mapper expects an Entity as its input, but passes an array to the DAO.

Galahad_Model_Dao

The Data Access Object (DAO) is what takes the actual data in your entity and persists it. The most common DAO is going to be a database, but a web service could be a DAO as could a filesystem or any other method of persisting data. The DAO is going to have similar methods as the DataMapper, but it expects just the data—nothing else (that’s why you need the DataMapper to fetch and process the data in your Entity). An easy way to show this is in code:

class Default_Model_DataMapper_User
  extends Galahad_Model_DataMapper
{
    public function save(User $user)
    {
        $dao = $this->_getDao();
        $dao->save(array(
            'name' => $user->getName(),
            'email' => $user->getEmail(),
            'date_modified' => time(),
        ));
    }
}
class Default_Model_Dao_DbTable_User
  extends Zend_Db_Table_Abstract
  implements Galahad_Model_Dao_Interface
{
    protected $_name = 'user';

    public function save(Array $data)
    {
        $this->insert($data);
    }
}

Notes

I’m going to reiterate one more time that this is a very early concept and that I’m looking for feedback. It could be that I’m thinking about things completely backwards and it all needs to be thrown away. At this point I certainly don’t recommend people running too far with these ideas until they’ve been discussed/thought out a little more.

About the Galahad_Model base class—since all the different pieces of your model will likely follow the same naming conventions, the Galahad_Model class provides some helper functionality to guess the name of classes. For example, inside of Default_Model_DataMapper_User you’ll probably need to get an instance of Default_Model_Dao_DbTable_User. So Galahad_Model_DataMapper provides a nice getDao() method to do this for you. If you’ve set the DAO, it uses that, but if you didn’t, it assumes you want a DbTable, guesses the name for you based on the DataMapper’s class name (so that if you choose My_Model_DataMapper_Person it’ll know to return a My_Model_Dao_DbTable_Person) and instantiates it for you.

Thoughts?

What do you think? Does this make any sense? Or am I trying to make a simple thing more complicated than it needs to be? I think a lot of this would make more sense in code, so maybe I’ll try to get what I have started cleaned up a little and attach it to this post. In the meantime, I’d love feedback (in the comments below, or to @inxilpro.

Well, that’s exactly what my Flickr/Tweetie Bridge does.  Just set it up, plug the URL into Tweetie, and you can start uploading/shortening with Flickr.  It hasn’t been very heavily tested, but it’s working fine for me.  Check out the 0.1 release.  It’s PHP5-only, and released under GPL.

Let me know if you come across any bugs, or have feature requests.

<link rev="canonical" rel="self alternate shorter shorturl shortlink" href="..." />

I haven’t yet implemented my own short URLs, but when I do I think that the way I’ll go.