dl

David Lundgren

Web Developer & Systems Administrator

ZfRest — RESTful-ness for Zend Framework 1

For both a client and my work we are working on creating a RESTful API. The problem is that all of the current solutions for Zend Framework are either one off (Resauce, ZfApiVersioning) or otherwise do not play well with a pre-built Zend Framework 1 application. The solution I was looking needed the following

  • handle API versions in the route (I know this isn’t in the spirit of RESTful)
  • handle OAuth
  • Plays well with ZF1 Module architecture (using a Module Bootstrap)

REST modules

In the end most of the solutions out there handle one thing or another but do not address the playing well with ZF1. Resauce deletes the default routes and sets it’s own root url (‘/’), this is not acceptable when you are trying to integrate it with an existing application. ZfApiVersioning suffered the same thing. The only available solution that I found was to write my own REST library for ZF1, so I am introducing ZfRest. It handles the requirements above, and more. The OAuth part is actually loaded as a plugin, requires PECL Oauth, and provides a basic way to handle using Oauth.

OAuth

I also needed an OAuth provider or server. Out of the few solutions I found for ZF1 (link: Zend_Oauth_Provider [incorrect naming], link: Oauth_Server [too complex]), I opted to just use the PECL OAuth module. I quickly ran into a problem where the Exceptions from an internal function were not being passed to my script when you pass in a path such as “/api/users”. Once I figured this out, everything was just working.

$oauthProvider = new OauthProvider();
$oauthProvider->consumerHandler('lookupConsumer');
$oauthProvider->timestampNonceHandler('lookupTimestampNonce');
try {
    $oauthProvider->checkOAuthRequest($uri, $method);
}
catch (Exception $e) {
    // Set HTTP response code to 403
    echo json_encode(array('statusCode' => 403, 'message' => 'Access denied to this resource'));
}

I’ve had several updates to problems I’ve found while using it, but overall I’ve found it works rather well.

Redux: PHP5 cronjob in Debian packages

After running into “session could not be started because it was already started with session_start() or session.auto_start” on a project, I realized that removing the cronjob is not the only thing that needs to happen to let PHP manage it’s own sessions.

  • chmod www-data:www-data /var/lib/php5
  • update /etc/php5/apache2/php5.ini and set
    session.gc_probability = 1

I’m assuming that this more paranoid than usual security measure was a way to help inexperienced admins and developers to help prevent session hijacking should the web server be breached. However, if root is gained, it doesn’t matter anyway. I’m not going to say that I am an expert in security for servers, but I can tell you that Debian, and therefore Ubuntu, are the only ones doing this type of paranoid security practice. Coming from the FreeBSD world, you are responsible for the security of your machine, not the developers or port maintainers.

</rant>