Archive for May 2012


Innovation’s Not The “Ah-Hah!”

May 25th, 2012 — 10:29pm

After reading through his “Confessions of a Public Speaker” (as a beginning speaker, I learned some good things from this one – I’d suggest it if you do any kind of speaking) I was anxious to check out some of Scott Berkun’s other books. The topics of some of the others didn’t really appeal to me, but the one that’s caught my attention recently is his “Myths of Innovation” book. I’m maybe a third of the way through it right now, and there’s one thing that keeps resonating in my mind as I go through it. In a previous chapter, he makes the point that innovation, despite what the history books and popular culture would have us assume – it’s less of an “Ah-hah!” and more of a “Finally!”.

See, most of the common stories of innovators out there leave out something that’s very important – the reference frame of their lives. They don’t provide a larger picture of who someone is (like Einstein or Newton) and how all of their work, everything they’ve done in their career led up to the discoveries that they’re known for.

I think this is important to remember as software developers, too. All of us start projects and never finish them, it’s just a fact of life in the world of a coder. We find something that we either think is the “Next Big Idea” or something that we’ll find amazingly useful and latch onto it, giving it our all for a week, maybe a month. Nine times out of ten, though, that project falls by the wayside. Now, don’t get me wrong, there’s some folks out there that do a great job with anything they touch, but for the average developer, it’s all about hacking away at the latest “shiny”.

Sometimes it’s about the technology (“everyone’s learning Backbone.js, why shouldn’t I?”) and other times there’s a bit of pride that kicks in (“I could do this so much better if…”) but there’s always one thing to remember. It doesn’t matter if the project you’re working on goes anywhere. Remember this. Just like some of the great innovators of the past, it takes a lot of dedication and work to get to be the “Ah-hah Guy” that wows the world with something new and amazing. Don’t forget that the code of the Next Great App isn’t just going to fly from your fingertips.

Work hard at your craft and it will pay off. Maybe not in fame and glory, maybe in making real, useful contributions to the culture and technology around you. Don’t stop trying to innovate, don’t focus on the failures and, above all, keep learning and keep doing.

4 comments » | Community, Development, Opinion, PHP

Composer Dependency Woes

May 15th, 2012 — 5:35pm

I spent the better part of this afternoon trying to figure out why a Composer installation wasn’t working and finally figured out the problem…it wasn’t mine.

First, a little context – I’m currently working on a testing presentation for some folks at work and I wanted to show them how to work with the Behat testing tool to create some handy functional/integration tests for our framework-based apps. I threw together a little framework (yes yes, I know) and got the PHPUnit tests set up and running in no time. When it came to the Behat tests, though, no matter what I did, I was still having a problem:

PHP Fatal error:  Class 'GoutteClient' not found in /www/htdocs/testing-examples/app/vendor/behat/mink/src/Behat/Mink/Driver/Goutte/Client.php on line 13

No matter how I tried to configure the composer install, it always gave me this message. I tried everything I could think of and, finally, at the suggestion of Rafael Dohms, checked out the github repository for the Goutte client (a href=”http://github.com/fabpot/goutte”>here). As it turns out, in the past day or so, there’s been a large change where Fabien implemented composer support on the repo.

Apparently this was what broke things – thankfully not something obvious I was missing.

So, how did I solve it so I could see the lovely green of passing tests again? Well, if you’re familiar with composer, you know there’s a composer.lock file that’s created after you install. When you run the “composer install” and it fetches from “fabpot/goutte”:”*”, you get this latest version that has the issues. A quick modification of the composer.lock file takes care of that though:

{
    "package": "fabpot/goutte",
    "version": "master-dev",
    "source-reference": "5ecceb7c28a428fb93f283982cc4f5edfd96630b"
},

See that “source-reference” setting? Well, that can either point to the branch or version you want to pull from or it can point to a specific commit. In my case, I just pulled the hash for the commit before all of the changes and dropped it in there. Then it’s just a matter of running a “composer install” to get the code from this commit instead. Don’t run an update though – that will wipe out your manual changes to the lock file and you’ll be back to square one.

Hope this helps someone out there who might be dealing with a similar issue regarding brokenness on an external lib!

3 comments » | Composer, PHP

Quick and Dirty REST Security (or Hashes For All!)

May 14th, 2012 — 5:44pm

So in working up a new RESTful service I’ve been tinkering with, I wanted to provide some kind of “authentication” system for it. I started to look into OAuth, but got a bit overwhelmed by everything that was involved with it. Looking for something a bit more lightweight (and simpler to implement a bit more quickly) I came across this older article with a suggestion of a private key/hash combination. I figured that could do the job nicely for a first shot, so I set to implementing it.

On the Server Side

I’m using the FuelPHP framework for this one, but that’s really only giving me a structure to work in and pull the request information from. This would work in most major frameworks (and even outside of one if you you’re a “do it my way” kind of developer). First off, let’s start with the controller side:

<?php
class Controller_User extends Controller_Rest
{
    protected function validateHash()
    {
        $request = file_get_contents('php://input');
        $requestHeaders = apache_request_headers();

        if (!isset($requestHeaders['X-Auth']) || !isset($requestHeaders['X-Auth-Hash'])) {
            $this->response('fail!',401);
        } else {
            // we have the headers - let's match!
            $user = Model_User::find()->where('public_key',$requestHeaders['X-Auth'])->get_one();

            if ($user !== null) {
                $hash = hash_hmac('sha256',$request,$user->private_key);
                return ($hash == $requestHeaders['X-Auth-Hash']) ? true : false;
            } else {
                return false;
            }
        }
    }

    public function post_index()
    {
        // return the user details here....
    }

    public function router($resource, array $arguments)
    {
        if ($this->validateHash() == false) {
            $resource = 'error';
            $arguments = array('Not Authorized',401);
        }

        parent::router($resource,$arguments);
    }
}
?>

There’s a lot going on here, so let me walk you through each of the steps:

  1. First off, we’re making a RESTful service, so we’re going to extend the Controller_Rest that Fuel comes with. It has some handy special routing. Our POST request in the example below would try to hit the “post_index” method and have its hashes checked in the process.
  2. Next up is the “validateHash” method – this is where the hard work happens:
    • The request and headers are read into variables for easier use ($request and $requestHeaders).
    • It then checks to be sure that both of our required headers are set (X-Auth and X-Auth-Hash). There’s nothing magical about these header names, so they can be switched out depending on need and naming preference.
    • If they’re there, the next step is to find the user based on the public key that was sent. This value is okay to openly share because, without the private key to correctly hash the data, your requests will fail.
    • The hash_hmac function is then used (with the “sha256″ hash type) to regenerate the hash off of the contents of the request and the private key on the found user.
  3. If all goes well, the request continues on and the “post_index” method is used. If it fails, however, the check in the “route” method of the controller makes a switch. It changes the currently requested resource to “/error/index” instead of what the user wants. This seamlessly shows the user a “Not Authorized” error message (401) if the hash checking fails.

A Client Example

Now, to help make it a bit clearer, here’s an example little script showing a curl request using the hashes:

<?php

$privateKey = 'caa68fb2160b428bd1e7d78fcf0ce2d5';
$publicKey  = '01fa456c4e2a2bc13e5c0c4977297fbb';

$data = '{"username":"happyFunBall"}';
$hash = hash_hmac('sha256',$data,$privateKey);

$headers = array(
    'X-Auth: '.$publicKey,
    'X-Auth-Hash: '.$hash
);

$ch = curl_init('http://mysite.localhost:8080/user');

curl_setopt($ch,CURLOPT_HEADER,true);
curl_setopt($ch,CURLOPT_HTTPHEADER,$headers);
curl_setopt($ch,CURLOPT_POSTFIELDS,$data);
curl_setopt($ch,CURLOPT_RETURNTRANSFER,true);

$result = curl_exec($ch);
curl_close($ch);

print_r($result);
echo "nn";
?>

You can see that both the public and private keys are specified (but on the PHP side, not visible to the user) and are sent as the “X-Auth*” headers as a part of the request. In this case, we’re POSTing to the “/user/enygma” resource and creating a user. To create the value to put into $hash, we use the same “sha256″ hashing method and salt it with the private key. This value – the result of the data+private key hashing – is then passed to the service who uses the controller code from above to validate that it’s correct.

It’s not a true “login” process, but it can help to validate that a piece of information known only to the user (the private key) and never shared directly, is known and matches the requests that the user sends.

You can find the code for this in this gist if you’d like something a bit more readable: https://gist.github.com/2697434

6 comments » | FuelPHP, PHP, REST

Back to top