Two years ago while I was working at dotMobi, I was one of the programmers working on the DeviceAtlas project, which launched at Mobile World Congress 2008. At the time, it was the largest launch I?d been involved in and it was quite a ride towards the end ? when you?re launching to 60,000 people [...]

PHP 5.2.13 has been released. The announcement is here and software is on the downloads page. At the same time, PHP 5.3.2 RC3 is available for testing, see http://news.php.net/php.qa/65489. There are only a few days before the final PHP…

Three years ago the Hardened-PHP project organized the Month of PHP Bugs. During one month I disclosed more than 40 vulnerabilities in the PHP interpreter in order to improve the overall security of PHP. In the history of PHP this event has been one of a kind. But now, three years later, my company SektionEins GmbH will continue in the same spirit and organize the Month of PHP Security. Our preparations are not finished yet, but here is a sneak preview of what it will be.

The Month of PHP Security will take place in May 2010 and will be very different from all the previews ?Month of Bugs? or ?Week of Bugs? events. You can think of the Month of PHP Security as a conference without a conference. This means around the 1st of March we will send out a call for papers in order to collect the best advisories, the best research and the best articles about PHP security. We invite everyone from the PHP and from the security community to take part in this event.

The basic idea will be that during May we are planning to release (at least) one advisory or one research paper or one article about PHP security topics that were submitted to the public. And in the end of May our jury will select the best X submissions and give out prizes. We are still in the process of selecting good prizes and would be happy about more sponsors. Therefore: If you consider this event to be a good idea to improve the security of PHP and want to sponsor prizes, do not hesitate to contact us at info@sektioneins.de.

The accepted topics will be:

• Advisory/Article about new vulnerability in PHP (with or without exploits) (no simple safe_mode, open_basedir bypass vulnerabilities)
• Advisory/Article about vulnerability in PHP related software (popular 3rd party PHP extensions/patches, like Suhosin or Zend tools)
• Detailed article about a single topic of PHP application security
• Article about a complicated vulnerability in/attack against a widespread PHP application
• Article about a complicated topic of attacking PHP (e.g. explain how to exploit heap overflows in PHP?s heap implementation)
• Article about how to attack encrypted PHP applications
• Release of a new PHP security tools
• Other topics related to PHP (application) security

Of course we will accept multiple submissions by the same person/team and there will most probably also be articles/advisories by ourself. (But of course we cannot win the prizes)

We at SektionEins are already very excited about the event and hope it will be a success and once again improve the security of the PHP ecosystem.

Overall the conference was pretty interesting since I don’t have a lot of experience with symfony I learned quite a bunch of things about it’s usage. I also met a lot of nice people, and ended the trip yesterday evening at the github meetup, after going for food with a couple phpBB guys who are really much nicer than the forum software they stand for. They were also very open to us bashing phpBB and seem to be headed towards a brighter future for the next version, which I’m sure nobody will complain about.

I also had my first session at a conference, accompanying Lukas though so I wasn’t really flying by myself yet but it was still a nice and interesting (and stressful) experience that I will try to renew. We didn’t get all that much feedback by the way so feel free to do so (also here if you are too lazy to register on joind.in), the organizers need it and obviously I wonder how the talk was received as well.

As for Symfony 2 (which now comes with a capital S please), I kind of saw the flexibility coming since we already implemented the dependency injection container in our Okapi framework at Liip, but I was still impressed by the jump away from symfony (1) Fabien conceded, many people would have tried to keep more BC at the cost of going forward, and I’m really glad he didn’t, I think it will pay in the long run. The new version of the framework will basically be able to be totally ripped apart to fit your needs better if you have high performance requirements, which was the major pain point of symfony 1 as far as I’m concerned, and one of our reasons to keep working on Okapi which is pretty much a baseline micro-framework you can build upon. We will have to see if adopting Symfony in its place will make sense, but it sounds promising and it would offload some maintenance away from us which is always good.

Obviously Symfony 2 isn’t going to be stable for a while, and there are some rough edges that still need to be discussed and improved, mostly in the way bundles are handled imo, but it looks very good already and I’ll definitely give it a try asap. I would also encourage everyone to do so, especially framework developers, because the dependency injection is a pretty awesome thing to have, both for the testability of code and flexibility of the development process. Although if it’s your only interest in it, checking out the Okapi 2 core (or the liip.to app ported to use it) is probably easier as there is less code to read, and we didn’t add any of the abstraction to the dependency injection layer that Symfony 2 has.

var win = XN.xnew({
    xtype : Gtk.Window,
    type: Gtk.WindowType.TOPLEVEL,
    listeners : {
        'delete-event' : function (widget, event) {
            return false;
        },
        destroy  : function (widget) {
            Gtk.main_quit();
        }
   },

   set : {
        set_border_width : [ 10 ],
        resize : [300, 300],
        show_all : []
   },
   items : [

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

I’ve been doing a lot of work with services and working with them in various ways from PHP. There are a few different ways to do this, PHP has a curl extension which is useful, and if you can add PECL extensions then pecl_http is a better bet but there are a couple of different ways of using it. This post shows all these side-by-side.

POSTing from PHP Curl

This is pretty straightforward once you get your head around the way the PHP curl extension works, combining various flags with setopt() calls. In this example I’ve got a variable $xml which holds the XML I have prepared to send – I’m going to post the contents of that to flickr’s test method.

First we initialised the connection, then we set some options using setopt(). These tell PHP that we are making a post request, and that we are sending some data with it, supplying the data. The CURLOPT_RETURNTRANSFER flag tells curl to give us the output as the return value of curl_exec rather than outputting it. Then we make the call and close the connection – the result is in $response.

POSTing from Pecl_Http

Pecl_Http has two interfaces – one procedural and one object-oriented; we’ll start by looking at the former. This is even simpler than in curl, here’s the same script translated for pecl_http:

This extension has a method to expressly post a request, and it can optionally accept data to go with it, very simple and easy.

POSTing from Pecl_Http: the OO interface

Finally let’s see what the OO verison of the extension looks like. Exactly the same call as both the above examples, but using the alternative interface, means our code looks like this:

This example is quite a bit longer than the previous one, and you might think this indicates that this approach is more complicated. In some senses that is true and its probably overkill for our extremely trivial example. However it is worth mentioning that the pecl_http extension is extremely flexible and powerful, and can handle some cases that the curl extension can’t. So even if it looks more complicated here, it can still be an excellent choice to implement.

In Conclusion

That was a very fast round-up of three ways you could make an arbitrary web service call from PHP – hopefully these examples are clear and will help anyone just starting to implement something along these lines.

A new Gartner report about PHP – PHP: Past, present and Future is mentioned in the last Zend newsletter. Even though I remain somewhat sceptical towards similar reports it is good to see that even Gartner is catching up. What they say actually do have an impact.

"PHP has been a cornerstone technology on the Web for more than a
decade. While its adoption among mainstream IT organizations has been
limited in the past, many corporate application development (AD)
projects are discovering the unique benefits of PHP."

One particular advice is especially interesting for large companies.

"Consider PHP as a supporting technology in a broader portfolio of AD
technologies, where it can provide a specialized toolset for building
Web graphical user interface (GUI) front ends to service-oriented
architecture (SOA) back-end services."

PHP is a fantastic tool for building rich web applications. It?s extensibility makes it versatile and extremely easy to integrate with modern integration solutions as Web Methods, legacy systems or just about any database technology.

To me – this has always been where PHP really shines.

Shipping code that works is crucial to retaining the support of customers and high quality in your application. While it?s impossible to ship code without any bugs at all, it is possible to control for as many as possible, and fix as many known issues as there is time. These strategies are designed to ensure that code works when it is shipped to the end user.

Work unit testing into your build process.
We talked about integrating your build process with a continuous integration server. With build engines like Phing, it?s possible to automate the unit testing process (and even the functional testing process to some degree).

Each time you make a build for release, you should know that all the unit tests pass. If they don?t, there?s a problem that should be addressed before the build is completed.

Use continuous integration to know when tests began failing.
To hit on the same theme, a solid continuous integration server will automatically run your tests and alert you as soon as the first one fails. This helps prevent regression ? the introduction of bugs into code that worked in previous releases. The time to discover regression isn?t when the build is due and the team is ready to go, it?s right after a commit, and continuous integration will help with this.

pExample Clutter program which will load a png and create a clickable button out of it./pimport clutterbr /br /#create a clutter stage and set the display sizebr/stage = clutter.Stage()br /stage.set_size(400, 400)br /br /#load the image for the buttonsbr /img=clutter.cogl.texture_new_from_file(‘button.png’,clutter.cogl.TEXTURE_NO_SLICING, clutter.cogl.PIXEL_FORMAT_ANY)br /br /#example create button from class startbr /br /class button(clutter.Texture):br / def __init_Read More…