PHP Community

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 "\n\n";
?>

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 &

Truncated by Planet PHP, read more at the original (another 733 bytes)

In a recent post to his blog Jeremy Cook has gotten back into looking at some of the SPL functionality that comes with PHP. In this new post he looks specifically at the IteratorAggregate and Iterator object types.

After a bit of a break I'm finally able to get back to writing about the predefined interfaces in PHP. PHP provides two interfaces that allow you to define how your objects behave in a foreach loop: IteratorAggregate and Iterator. Before taking a look at IteratorAggregate I'll briefly discuss how we can iterate over objects in PHP 'natively' and what it means to be Traversable.

He introduces the concepts being being "iteratable" and "traversable". He then shows how to implement the IteratorAggregate (only one method required, "getIterator") and Iterator ("next", "valid", "current" and "key" methods required) in classes of your own.

You can find out more about these two object types (including more sample usage) on their manual pages: IteratorAggregate & Iterator.

Marcelo Gornstein has returned to his "IVR with PHP" series in this latest post (see others here and here). In this new post he shows you how to create a full flow of interaction for your callers:

The last article was about how to create call flow nodes for asterisk, using pagi and php, to easily create telephony applications. It's now time to add a layer on top of it, and create a complete call flow with several nodes.

He talks about NodeControllers to control execution flow, results from their execution, available actions and an example of creating a controller and adding nodes. He builds on this simple controller and shows how to handle a few actions including responding to user feedback, adding multiple menu options and some more complex logic using a closure to contain the functionality.

Lukas Smith is looking for feedback about a question that's been in his mind a lot lately - can the handling of query parameters be made better for the Symfony2 framework (and even easier to use).

Obviously you can already access query parameters today already but it could be easier. Essentially what I want is a way for developers to easily configure what query parameters they expect and what values they expect. This is useful for several things like easier reading and validating of query parameters, self documenting API both for API docs for humans but also for machines.

He's asking for feedback and ideas from the community on a proposed solution that could make things more flexible. He also briefly mentions the route matching and how qurey parameters could cause them not to match:

For one I don't think that a mismatch on a route requirement of a query parameter cause the route to not match. However then it can quickly become confusing for the end user or it would require adding more and more syntax to handle all the different cases.

In this new post to his blog Gonzalo Ayuso has shared a simple SQL wrapper that he uses to work with his databases. It takes in an injection of the database connection component (a href="http://php.net/pdo">PDO) and provides functionality for inserts, updates, etc. with transaction support.

If we don't use an ORM within our projects we need to write SQL statements by hand. I don't mind to write SQL. It's simple and descriptive but sometimes we like to use helpers to avoid write the same code again and again. Today we are going to create a simple library to help use to write simple SQL queries.

It's a lightweight library that'd be good for basic uses, but when you start getting into something a bit more complex, something like Doctrine2 or Propel might be a better solution (or whatever your framework of choice has built in).

There’s been quite a bit of talk, recently, in PHP-land about templates and the ramifications of enforcing “pure” PHP scripts by preventing scripts from entering html mode. I’m not quite sure how I feel about this RFC, but it got me thinking about the whole idea of using PHP for templating in modern web apps.

For many years, I was a supporter of using PHP as a templating language to render html. However, I really don’t buy into the idea of adding an additional abstraction layer on top of PHP, such as Smarty (and many others). In the past year or so, I’ve come to the realization that even PHP itself is no longer ideally suited to function as the templating engine of current web applications — at least not as the primary templating engine for such apps.

The reason for this evolution is simple: modern web apps are no longer fully server-driven.

PHP, as you know, is a server technology. Rendering html on the server side was fine for many years, but times have changed. Apps are becoming more and more API-driven, and JSON is quickly becoming the de facto standard for API envelopes.

We can no longer assume that our data will be rendered in a browser, nor that it will be rendered exclusively in html. With Gimme Bar, we render html server-side (to reduce page load latency), in JavaScript (when adding or changing elements on an already-rendered page), in our API (upcoming in a future enhancement), in our iPhone app, and certainly in other places that I’m forgetting.

Asset rendering in Gimme Bar can be complicated — especially for embed assets. We definitely don’t want to maintain the render logic in more than one place (at least not for the main app). We regularly need to render elements in both html and JavaScript.

This is precisely why we don’t directly use PHP to render page elements anymore. We use Mustache (and Mustache-compatible Handlebars). This choice allows us to easily maintain one (partial) template for elements, and we can render those elements on the platform of our liking (which has been diversifying more and more lately, but is still primarily PHP and JavaScript).

Rendering elements to html on the server side, even if transferred through a more dynamic method such as via XHR, really limits what can be done on the display side (where “display side” can mean many things these days — not just browsers).

We try hard to keep the layers our web applications separated through patterns such as Model/View/Controller, but for as long as we’ve been doing so, we’ve often put the view bits in the wrong place. This was appropriate for many years, but now it is time to leave the rendering duties up to the layer of your application that is actually performing the view. This is often your browser.

For me, this has become the right way to do things: avoid rendering html exclusively on the server side, and use a techonology that can push data rendering to your user’s client.

On PHPMaster.com they've posted the third part of their series looking at development around RESTful APIs. In this latest article they take an outsider's perspective and look at using services rather than creating one from scratch. (Part 1, Part 2)

Imagine it's a warm, sunny, summer day. You're just walking along, taking a leisurely noonday stroll, when all of a sudden you come face to face with a RESTful API. What do you do? How do you interface with it? Or, as those of us in the know would say, "how do you consume RESTful services?" That, my friends, is the subject of this article.

They mention using other tools (like components/features of common frameworks) to interface with the services, but end up using the curl extension to make a POST request to a service to add a few events to a "/summerschedule" resource.

On the EngineYard site today there's a new podcast released with Elizabeth Naramore interviewing Derick Rethans (of 10gen) about MongoDb and the OpenStreetMap project.

Derick gives a little background about himself (including being a PHP evangelist for 10gen) and how he ended up working with MongoDB. They talk about how MongoDb is different and some of the involvement he has in contributing to open source projects and the OpenStreetMap project.

You can listen to this latest episode either via the in-page player or by downloading the file directly.

Latest PEAR Releases:

• PHP_UML 1.6.1
• HTTP_Header2 0.1.0
• Services_PageRank 0.1.0
• Services_Libravatar 0.2.0
• Auth_PrefManager 1.2.2

In July, I'm speaking at OSCON. Actually I have a few interesting speaking engagements coming up, and I haven't got around to adding upcoming dates to my blog yet but I'll be at phpDay in Verona next week with a talk on API Design and DPC in Amsterdam in June with a tutorial on Web Services and a talk on what OAuth is actually for.

OSCON is special because I have always wanted to go and never imagined it would actually happen. Every year I read the list of sessions from the year before, and decide that I absolutely must submit to the call for papers, regardless of how small I think my chances of being accepted are! I've submitted a couple of times in the past, excluding last year because I was newly freelance (OSCON does not cover any speaker expenses at all, they just give you a conference pass. That's kind of hard going for those of us self-funding halfway across the world, and last year, I just couldn't do it. This year I still can't really justify it but I'm going anyway!)

I have two talks, both of them brand new, and I'm excited about them both!

PHP 5.4 Features You'll Actually Use

When I told one of my local user groups (how excellent to have more than one local user group!) about this talk they said "that'll be a short talk" and I am a little worried they are right! Cool new array syntax, traits, and a web server ... am I missing anything important? To make this even easier and more fun, Rasmus has the slot immediately before mine and his abstract includes "a detailed review of new PHP 5.4 features". I feel like a spare part and I haven't even written the talk yet!

Get Some Rest: Best RESTful API Practices

This one will be lots of fun, because I firmly believe in writing services that make users, rather than textbooks, very happy. Which means that I do break the rules and I think there are times when that's acceptable. I suspect that there will be heckling, flaming, and foaming at the mouth involved but hey, I'm not there to be popular! Honestly, I love REST, I think it's possible to take it too far, and I'm only a little bit scared to say that in public :)

OSCON Conversations

OSCON does a cool thing where it opens the comments on a talk page immediately - which means that you can already go and ask questions, make requests, or leave comments on either my PHP 5.4 talk or the RESTful one and let me know what you do (and perhaps do NOT) want to hear. If you're going to OSCON or are just interested in the topics, I'm interested to hear your thoughts, either over here in the comments or over on the talks themselves!

Lorna is an independent web development consultant, writer and trainer, open source project lead and community evangelist. This post was originally published at LornaJane

The PostgreSQL Global Development Group announces the beta release of PostgreSQL 9.2, which will include major increases in performance and both vertical and horizontal scalability. The PostgreSQL Project asks all users to download and begin testing 9.2 Beta as soon as possible.

Major performance and scalability advances in this version include:

• Index-only scans, allowing users to avoid inefficient scans of base tables
• Enhanced read-only workload scaling to 64 cores and over 300,000 queries per second
• Improvements to data write speeds, including group commit
• Reductions in CPU power consumption
• Cascading replication, supporting geographically distributed standby databases

PostgreSQL 9.2 will also offer many new features for application developers, including:

• JSON data support, enabling hybrid document-relational databases
• Range types, supporting new types of calendar, time-series and analytic applications
• Multiple improvements to ALTER and other statements, easing runtime database updates

For a full listing of the features in version 9.2 Beta, please see the release notes.

We depend on our community to help test the next version in order to guarantee that it is high-performance and bug-free. Please download PostgreSQL 9.2 Beta and try it with your workloads and applications as soon as you can, and give feedback to the PostgreSQL developers. More information on how to test and report issues

Get PostgreSQL 9.2 beta, including binaries and installers for Windows, Linux and Mac from our download page.

Full documentation of the new version is available online, and also installs with PostgreSQL.

[This blog post is also available in German.]

 

Yesterday, it was the news of the day: Magento CE 1.7 was forked on GitHub by some community people. After the spectacular departure of Yoav Kutner, then-CTO at Magento (TechCrunch reported), it was just a matter of time until Magento was forked. Indeed, as Vinai Kopp pointed out on twitter, there have been some forks of Magento already (project agent-ohm, a fork of Magento 1.3), but Mage+ seems to be another case.

What are the reasons of the fork of Magento? And what's in it for the Magento community?

Continue reading "Magento CE 1.7 forked on GitHub"

So this topic has been going back and forth in my head a lot over the last months: how do we best handle query parameters in Symfony2? Obviously you can already access query parameters today already but it could be easier. Essentially what I want is a way for developers to easily configure what query parameters they expect and what values they expect. This is useful for several things like easier reading and validating of query parameters, self documenting API both for API docs for humans but also for machines. Now thanks to Alexander we have a solution that works. But there is the big question if this is really the right approach. For now ignore the fact that it only works with annotations for now, because that is fixable. But it does point to the question if this shouldn't be integrated into the routing configuration itself by adding query support for our implementation of uri-templates.

While this at first seems like the right place for this sort of configuration, it raises the questions of its own since path parameters (i.e. /{foo}) should be handled differently than query parameters (i.e. /{?bar}). For one I don't think that a mismatch on a route requirement of a query parameter cause the route to not match. However then it can quickly become confusing for the end user or it would require adding more and more syntax to handle all the different cases.

Feedback much appreciated!

In the wake of the success of the PSR-0 standard (used in autoloading structures across frameworks and various applications), the PHP-FIG (Framework Interoperability Group) has start on drafts of other standards to help provide some guidelines to standardize PHP development across projects.

Among the group, Paul Jones has been writing serveral proposals under the PSR-1 standard banner that include:

• The basic draft of the standard
• An extended draft of the same
• A more advanced version, PSR-2 that also includes some survey results on various syntax elements.

If you want to know more about the PHP-FIG group, you should listen to this excellent panel interview of the group from the Voices of the ElePHPant podcast. Paul and others get into the point of the group and how the standards are progressing.

Tom Barrett has a new post that shares an opinion he has about WordPress and what it can be used for - that the popular software is more than just a blog, it's a PHP framework.

A software library is a collection of resources used to develop software. [...] A Software Framework is a software library with certain goals in mind [...]. Hopefully theme and plugin developers will be familiar enough with WordPress to see where I am going with this.

He mentions some of the similarities WordPress has with other PHP frameworks including the integration of hooks/filters/plugins, working with core files that are maintained by an external entity and that it's a full-functional CMS out of the box.

From this, I conclude that WordPress is a framework. It provides us with a library of resources that allow us to extend and specialize it into the site and CMS that we want.

In this new post from Anson Cheung, he shows you a way to easily create nodes in an eZ Publish-based application, importing content, XML and files/files.

Node creation in eZ Publish by using PHP is not well documented. However, when you encounter a large number of contents need to be insert periodically. You would ask is there any way to automate the content insert function with script in eZ Publish??? Any here I am going to summarize the way to achieve.

He includes the code examples showing how to:

• Set the creator
• Import generic content and attaching it to a parent node
• Importing some XML content
• Adding an image or file record that points to a local file

Here is a quick update on conferences we will attend and speak at in the next couple months. If you are attending any, feel free to come and say hi!

Next week our entire team will be at jsDay and phpDay in Verona, Italy. If you haven’t got tickets yet, hurry up because it is about to be sold out.

Pierre will talk about Backbone.js, Igor has two talks about realtime apps with websockets and the Silex microframework and I myself will be talking about managing your dependencies with Composer.

In June there are two notable events. The first is SwissJeese. A local JavaScript-oriented conference co-organized by Pierre that will be in Bern. It is free and on a Saturday so there is really no excuse not to come if you have an interest in JavaScript. Register for free on eventbrite!

The second a week later is Symfony Live in Paris which we are always looking forward to.

If you get a chance to go to both phpDay and Symfony Live, you can follow Igor’s second talk about Silex, which will be more advanced given the audience is already more familiar with the Symfony Components. If you miss Verona you can catch up on my Composer talk in Paris as well. William will hold an introduction to the Propel2 ORM and even you have no interest in PHP I will present the Redis key-value store so you can come anyway ;)

We sure hope to see some old friends and make new ones there, so if you were hesitant to come, just register before it’s too late!

When it comes to Object Oriented Programming, there is no shortage of guidelines and principles for how to properly design an OO system. There is also no shortage of acronyms to describe these principles: DRY, SRP, LSP, LoD, ISP, OCP, etc. However, there are two acronyms that really shine through to describe how to, and how not to do OOP well. The two acronyms are SOLID and STUPID (respectively). We'll discuss some of the underlying principles of Object Oriented Programming, and how we can learn from the principles identified by each of these two acronyms. Additionally, we'll explore some additional anti-patterns of Object Oriented Design and how they can be avoided. Finally, we'll talk about how all of this applies to our every day development tasks, and the real-world benefit these design principles provide...
If you plan on attending, be sure to RSVP first! If not, the talk will be streamed via ustream.

It feels like every minute a PHP developer somewhere on this planet starts implementing something aching to a CMS from scratch. Some do it because their project is "so big" it that it "obviously needs" a custom solution. Some do it because their project is "so small" it "obviously needs" just a few days of hacking .. to build a custom solution. Let me briefly focus on the later group. Working in a company with less than 10 people building websites for customers a project needs a bit of a CMS to manage those 10 "semi static" pages seems to be the poster child example of this group. The devs whip up a DB table, slap an ORM in front, maybe even use some generator for the admin UI. Done. Later the clients also wants versioning and luckily many ORMs provide some solution for that. Easy. Permissions? Most frameworks provide some ACL system. Child pages? ORM has some tree algorithm supported. Fulltext search? Integrate ElasticSearch. Custom page types? Uhm well by now you have enough sunken costs that you will make that happen somehow too. Some morning you wake up and you have created the next Drupal or Typo3. If you did, then it would be hard to claim that you did it wrong because both are very successful projects. What PHPCR aims to be is to provide you with a short cut for this path. Or in other words there should be a PHPCR implementation that is so easy to use, with so many helpful higher level components in your favorite framework, that it becomes the natural choice for your next CMS needing project.

Every time anyone talks about PHPCR, they will mention Jackrabbit sooner or later as it is the basis for the currently most mature PHPCR implementation. Here, I just did it too. Jackrabbit requires Java. More importantly it is not trivial and most of you have never heard about it, let alone used it. I think for many high scale use cases its great that PHPCR has been integrated with Jackrabbit, but it needs to be relegated to a side note you mention when someone starts talking about scaling to millions of documents and many GBs of data. Once there is a PHPCR implementation that works with pure PHP, using any RDBMS (including SQLite which is bundled with PHP) it will become easier to just use that instead of whipping up your own tables. No more convincing the sys-admin guy about adding a new daemon to the setup. Instead being able to tell the client what other features they could get in the next code sprint.

So today, we are not there yet. We have an implementation of PHPCR that works on top of Doctrine DBAL to in theory support any RDBMS. Well in reality it already does though the search API only works with MySQL and PostgreSQL. It also doesn't support versioning and ACLs. Oh and if you drop more than 50 documents into it, search performance will start to hurt quickly. Bummer. But there is good news too. The core infrastructure is laid out thanks to Benjamin. Progress on it, while not rocket fast, is continuous thanks to Liip intern Adrien .. as a matter of fact if you go to our demo page it would run all but the admin interface on top of it just fine (yes this includes the cool inline editing!).

I believe that a decently experienced database developer would need a man month to fix up the searching to perform decently unto lets say 1k documents as well as implement simple versioning on top of SQLite. Another 2 man months should enable implementing permissions and support for even more documents, ACLs and a few other goodies. Is this something that a 10 developer company can commit to when offering that simple CMS solution to one of their customers? Obviously not. This takes a few developers who are willing to invest into the future. Until they come along unfortunately PHPCR will continue to not be a viable option for many small CMS projects.

Update: In this post I failed to mention that there is also already a pretty solid implementation of PHPCR written in C by the Midgard team. However just as a Java solution can't be our pitch, I believe that a custom extension cannot either.

So that I don’t forget how to do this next time around. Worked for me, your mileage may vary.

First step is to get a working install of PHP.

1. Download PHP 5.4.latest ZIP file from the PHP Windows website
2. Unpack the ZIP file into c:\php. You should end up with c:\php\php.exe
3. Copy c:\php\php.ini-development to be c:\php\php.ini
4. Edit c:\php\php.ini to suit (e.g. set date.timezone)
5. Make sure you add c:\php to your system PATH (via Computer’s Advanced Properties -> Environment Variables)
6. Reboot (this is Windows, after all :)

At this point, you should be able to open up a Command Prompt, and type ‘php -v’, and see the response ‘PHP v5.4.latest …’ appear as expected.

Now for PEAR itself.

1. Open http://pear.php.net/go-pear.phar in a browser, save this file into c:\php
2. In a Command Prompt, cd to c:\php and then run “php c:\php\go-pear.phar”
3. At the prompt, select ‘system’. A text menu of paths will appear
4. Fix the default path for pear.ini (option 11) to be c:\php\pear.ini
5. Fix the default folder to look inside for php.exe to be c:\php
6. Make sure the binaries folder (option 4) is c:\php
7. Check all of the other options, make sure they are prefixed with c:\php
8. Press ENTER, and you should see PEAR downloading various PEAR packages onto your system
9. Double-click the PEAR_ENV.reg file in c:\php
10. Reboot again to make sure PEAR_ENV registry entries have taken effect

At this point, PEAR is installed and should be available to use in your own projects, or with something like Phix.

Personal Notes

Some reminders to myself for the next time I have to do this.

• Documentation for PHP for Windows and PEAR for Windows both seem to be out of step with current downloads. There’s currently no Windows installer for PHP available, and the PHP .ZIP file doesn’t contain the ‘go-pear.bat’ file.
• You have to pay close attention to the default folders offered when running ‘go-pear.phar’. They appear to use the current working directory as the prefix even when installing system-wide, except for the location of pear.ini and php.exe – neither of these defaults are sane, and must be manually changed during the install :(
• After install, pear command doesn’t seem to be 100% compatible with its behaviour on Linux and OS X. -D switch didn’t work, there may be other problems too that I haven’t yet found.
• Both reboots are required – I’m not taking the piss there – for all running Windows apps to pick up the changes.