Custom Callbacks with Invoke

In putting the Invoke library to use I noticed something. While I could tell it to check for groups and permissions on the current user and limit HTTP methods on the request, there were more complex things I needed to check that weren’t part of these defaults. Now, I could just extend invoke to include match types for everything I needed (injecting a custom match class based on my needs) but I wanted something a bit more generic that I could use to call my own logic and return the pass/fail result.

So, I added in the “object.callback” match type that allows you to call a static method in your own code and perform the evaluation yourself. Here’s how it works. Say you have this configuration in your routes.yml file:

  protected: on
  callback: \App\MyUser::test

This tells Invoke that when the user requests the /foo URL, the protection should kick in. It then goes into the checks portion of the process. This sees the special callback option and looks the class and method to call. In this case, we’ve told it to try calling the test method \App\MyUser. This class needs to be autoloadable so that Invoke can directly call it and its static method. Yep, that’s right – it needs to be a static method but you’ll be provided with everything about the request in the incoming $data variable. Here’s what the method should look like:

public static function test(\Psecio\Invoke\Data $data)
  /* perform your evaluation here and return a boolean */

In the $data variable there, you’ll have access to the context of the application via some object properties:

  • user: The current InvokeUser instance (ideally where your user lies too)
  • resource: The resource that was requested (includes access to the requested URI)
  • route: This is the route match from Invoke’s configuration the current request matches. This contains the route regex match, the configuration options and any additional parameters passed along

For example, say you needed to get the parameters from the request to do further evaluation. You could fetch them through $data->resource->getParams() and get the associative array back.

Adding these callbacks makes the Invoke system a lot more flexible and allows you to create those custom match types without having to have whole other classes just to perform your checks.

Invoke and Gatekeeper for Route Authentication & Authorization

As a part of a new project I’m working on (personal, not work) I came across a common need to enforce authentication and authorization handling in a bit more automated way based on the URL requested. I looked around for options and didn’t really find many that could be implemented somewhat simply but I did like the way Symfony defines their YAML to enforce auth* on the various endpoints. I set out to make something similar but a little simpler and ended up making Invoke.

It’s a super simplified version of the YAML-based routing and only has functionality for checking groups and permissions right now, but that’s not what I really wanted to talk about in this post. Invoke is fun and all, but I wanted to show how I’ve integrated it with another more robust tool I’ve written, Gatekeeper. The goal of Gatekeeper is to make a simple drop-in authentication system for applications to take care of a lot of the boilerplate user management needs. It comes with the usual CRUD handling for users, groups and permissions (RBAC) and also supports password resets, security questions and “remember me” functionality. Again, Gatekeeper is a cool library but it’s not the primary focus here. I wanted to integrate the two libraries so I could let each do what they do best – Invoke to check the current user against a set of criteria and Gatekeeper to provide the data for this validation.

Invoke lets you hook in your own users via a `UserInterface` that you can implement in your own application. In this case Gatekeeper has a concept of users too, but they don’t exactly mesh with what Invoke is expecting. So, let’s make an Invoke-compatible user object that it can use for it’s checks. This is the real key to the integration:

use \Psecio\Gatekeeper\Gatekeeper as Gatekeeper;

class InvokeUser implements \Psecio\Invoke\UserInterface
  private $details = array();

  public function __construct(array $details)
    $this->details = $details;

  public function getGroups()
    $groupSet = array();
    $groups = Gatekeeper::findUserById($this->details['id'])->groups;
    foreach ($groups as $group) {
      $groupSet[] = new InvokeGroup($group);
    return $groupSet;

  public function getPermissions()
    $permSet = array();
    $permissions = Gatekeeper::findUserById($this->details['id'])->permissions;
    foreach ($permissions as $permission) {
      $permSet[] = new InvokePermission($permission);
    return $permSet;

Then, we’ll define the Invoke configuration in a YAML document:

  protected: on
  groups: [test]
  permissions: [perm1]

In this case we’re telling Invoke that when it sees the requested URL of `/event/add` it should check a few things:

  • That the user is authenticated (protected: on)
  • That the user has a group with the “name” attribute of “test”
  • That the user has a permissions with the “name” attribute of “perm1”

If the user passes all of these checks, they’re good to go. Here’s how that would look in the execution of the Invoke code:


$en = new \Psecio\Invoke\Enforcer(__DIR__.'/config/routes.yml');

// If you're already using Gatekeeper for user management, you
// can just use this:
$userData = Gatekeeper::findUserById(1)->toArray();

// Otherwise you can push in your own user data
$userData = array(
  'username' => 'ccornutt',
  'id' => 1,
  'email' => ''

$allowed = $en->isAuthorized(
  new Confer\InvokeUser($userData),
  new \Psecio\Invoke\Resource()

if ($allowed === false) {
  // They're not allowed on this resource, forward to an error!


The Invoke Resource by default looks at the current REQUEST_URI value so no options are needed when it’s created.

I’ve found this a pretty simple way to integrate these two libraries while still maintaining the correct separation of concerns enough to let each tool do their job. I’m always welcome to feedback on both projects or, of course, PRs if you find something that needs improving or a bug to fix.

Here’s more information about each of them:

Development Security isn’t an Add-on

Thanks to O’Reilly’s “DRM Day” promotion yesterday, I picked up a copy of a book I’ve been meaning to but could justify because a) full price of the ebook is around $25 USD and b) it was written back in 2003 – almost ten years old! The book, “Secure Coding: Principles and Practice” is more of an overview of things to think about when it comes to secure development and less about specific language-related tips. What’s interesting to me is that, despite the book being 10 years old, it seems like the same challenges they were facing then, we’re still facing now.

Even the introduction reinforces something I’ve been trying to advocate in the PHP community for a while now – security is not an “add on” that you can drop in at the end of the development process. Security must be a part of the planning and architecture of your applications from the beginning. If you “go back and secure things” you’re doing it wrong. Now, this doesn’t mean you have to have some kind of security review process retrofitted into your SDLC. I know of lots of teams that have their workflow down and are cranking out the code and features like there’s no tomorrow. How does a team like this start “thinking secure” without having to add a lot of extra overhead? It’s pretty easy really – all it really takes is a shift in mindset.

When most developers I know start out on problems, they ask themselves questions to figure out how to start in on their solution. They wonder about things like the “best way to do it” or “the most efficient way” to get the job done. Their minds start filling up with object structure and SOLID principles, trying to find the best solution (and maybe even technologies) for the job. To start thinking secure, all it takes is one more question:

How can I break this?

Easy, right? Well, like anything else in development, one question always leads to at least 10 more. This one simple question sets you down the right path, though. It’s too easy to get focused on making things work and writing up unit tests that pass when everything’s good. I want to challenge you as a developer to do one thing in your next project. I want you to take a step back from the code – maybe grab a fellow developer to help – and look at the application from the outside and determine what could be exploited and where (the “attack surface“). A lot of times this is easier when you’re not neck deep in the code, so if you have doubts, find an outsider.

Here’s some related articles I hope can help get you in the right state of mind as you work to integrate secure principles into your development. There’s lots of other topics in there that devs would find useful, but this will get you started:

Let’s all help make the integration of security and development a thing of the past. Then, ten years down the line, people wil be reading books from 2013 and wonder what it was like “before”. 🙂

“It Depends”

In my research and writings that I’ve already done, I’ve noticed something about trying to share helpful security advice to fellow developers – you can provide all of the code examples and describe the threats all you want, but the problem really boils down to two words:

“It depends”

Much like other development-related issues, there’s a lot of things you have to take into consideration when thinking about the security of your application. Code security by itself is good, and there’s some best practices for that that have been shared all over the web. Unfortunately, this only paints a small part of the picture. Web applications, by their nature, are really complex systems composed of multiple pieces of software all running together to make this useful, functional service for its consumers. If you’re a PHP developer, there’s things you can do to help prevent common attacks (like XSS, CSRF or SQL injection to name some popular ones), but unless you look at the bigger picture, you’re getting a false sense of security.

“But I’m only responsible for the code!” you say. You like the idea that your code can be as secure as possible by filtering output, escaping user input and using defensive coding techniques. You commit your code, run your tests and happily go about your business, thinking things are good. Unfortunately, if you don’t consider the ecosystem your application lives in, chances are you missed something.

I’m not talking about code challenges here – preventing things like XSS or SQL injections is relatively easy (as long as you know what to do). The problems I’m talking about are things that may be true for one environment but not for another – things like:

  • Working with multiple databases and storing their credentials securely
  • Effective logging to a remote syslog server
  • Potentially protecting your data from a physical intrusion
  • Working with sensitive data
  • Bridging authentication/authorization across applications
  • Concurrency issues coming from multiple installations of the same application

While a lot of these kinds of concerns revolve around the architecture of the application, developers still need to keep them in mind when creating their applications. At the very least, you need to keep these kinds of concerns in mind when writing your code. Like anything else, there’s ways to structure the code to make things like this simpler to change. The trick is to keep things loosely coupled enough to make life simpler down the road.

Innovation’s Not The “Ah-Hah!”

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.

Book Review: “Code Simplicity”

Last night I finished my latest read from O’Reiily, Code Simplicity – The Science of Software Development. I spotted the book the other day when O’Reilly was running a special on a few books and the ebook was cheap so I figured it couldn’t hurt to give it a try. After all, the “science” part in the title made it sound like there might be some hidden truths that could be applied anywhere in development. Unfortunately, most of the book just ended up being more of a rambling journey though things that most software developers that have any years of experience (even the bad ones) would already know.

The author spent a good bit of the book dedicated to definitions and explanations about various practices and ideas in development, as if he thought that maybe the audience reading the book wasn’t savvy on the topic. The first few chapters also included several sections about the book itself – why it was relevant and mentions of a “science” that never seemed to fully resolve. Granted, trying to make a “science” (more a set of laws than just best practices) out of something so varied as software development is a pretty difficult task, but I felt like the author tried a little too hard to make his case for the book and less time actually defining something that could have been interesting.

All this being said, if you don’t worry too much about him trying to propose a “science” to it all, there were some good best practices reminders in here for developers of any language:

  • Don’t rewrite, rework – a reminder that, despite it seeming easier to chuck the whole system and start over with the knowledge you now have, you’d do better in the long run to change things from the inside out, a piece at a time (hint: unit tests make a world of difference here)
  • Know the problem before writing the solution – listen and understand the problem before you start with even one piece of code. If you don’t fully understand the problem, you’ll end up with half-assed software that only does part of what was needed.
  • Think specific, not general – if you immediately jump to the “well, if I use a plugin architecture for this part…” chances are you’ve already added too much complexity. Think small first – make it work, then make it better (I’m a big fan of iterative development)
  • Use more experienced developers as a sounding board – chances are, if someone’s been in the development biz longer than you, they’ve come across your situation before. Sometimes you have to seek out that person on a specific topic, but don’t just forge ahead blindly. At the very least, try to find blog posts or articles that you can use as a guide.
  • Don’t forget that time is important too – most developers (me included) easily forget that time is a factor in their development. No, I’m not talking about the actual time to write the code or the looming deadline to finish it by. I’m talking more about the time you’ll need to do research, try things out or even consult with fellow developers. Time put into something to gain knowledge is an investment too…don’t forget to remember the value of it.

There were other points made throughout the book, some more relevant than others, but I wish the author had spent less time focusing on definitions and more on expanding the sections with some more practical advice. This (relatively short) book probably could have been summed up in a small series of blog posts and been just fine.

Book: Code Simplicity – The Science of Software Development
Publisher: O’Reilly
Author: Max Kanat-Alexander
Pages: 92

The Accidental ScrumMaster

Since my role has changed over the past few months away from being a pure developer to a lead of an agile (scrum) group here, I’ve started blogging some about my experiences over at The Accidental ScrumMaster:

Let me start off by saying this – I have been a developer for just about all of my professional career (with some syadmin and networking tossed in to spice things up). I’ve helped to lead other developers in projects where we were focused on just the software and didn’t have to worry too much about outside forces. At my current job, this has changed. Over the last few months, due to some changes in staffing (read that as “people moved on”) holes were left in the team for certain roles. Before those people transitioned out of their jobs, they started to approach me with some of the responsibilities they had and showed me the ropes.

Suddenly I wasn’t just another developer anymore – I was the person managing our Jira project, I was the one doing the code merges and releases and I was the one tracking the progress of the project on a day to day basis.

I hope what I post there can be beneficial to other developers out there who find themselves with extra the responsibilities of making agile happen in their jobs.