David Lundgren

Web Developer & Systems Administrator

The allure of static proxies

Several weeks ago I started playing with Laravel. Primarily because several colleagues are using it, and have suggested that I take a look at it. During my time reviewing how to build a view template I came across references to Html, Form, View and other static calls. Initially I was not impressed due to the use of so many static calls. I have come to an understanding about how static calls in certain circumstances can actually enhance code readability.

Continue reading

pure-authd external script failing

I have a PHP script handling authentication for pure-authd, and the problem is that it fails. After a reboot it is still failing. If I log in, restart it manually and monitor the log files, it works. As soon as I log out it fails!

I’ve come to the conclusion that pure-authd doesn’t properly daemonize, and detach from the controlling terminal. PHP was actually using fsockopen to another server and it stopped being able to use DNS because I logged out of the shell.

I ended up switching to the IP of the server. While this is not the ideal solution, it works because internally the IP is a reserved DHCP address for the server, and we shouldn’t be updating the server any time soon.

When does Dependency Injection become an anti-pattern?

During my tenure as a seasoned, and tenderized, PHP developer I have used many design patterns: adapters, factories, data mappers, facades, etc. The most recent one that I have been working with is Dependency Injection. Inversion of Control is not a new idea, at least not in the programming world, but in the PHP world it seems to have taken us by storm in recent years. Every framework will often have a Dependency Injector built in, or offer it as a component for use. It is the hip thing to do in PHP, but I believe we need to take a step back and evaluate it for what we are really trying to achieve. That is reducing the tight coupling that our objects may have. I view it as removing the new-able’s from our objects code, and handing the object creation over to something else to deal with. Read further on how I believe DI can become an anti-pattern.

Continue reading

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.


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();
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.


Next Page »