Johan Mares has a recent post about using PHP on the command line:

I already knew how to run PHP scripts from the command line (CLI), although I never really used it. What was new to me was that there are 2 ways of doing this. The first one is by using the php command and the second, and new for me, is by adding a shebang on the first line of your script.

His first way is to run the PHP file through the interpreter directly (via a command line call to something like "php myfile.php"). The second it to actually include the path to the interpreter inside the PHP file itself and use the shell to execute the contents based on that (adding something like "#!/path/to/php" at the top). Then you just make the file executable and you can run it like any other binary file.

Ian Selby has posted a new tutorial today looking at something that can be very handy in the right situations - dynamically adding new functions to an already defined PHP class.

I've gotten a lot of great suggestions for features [for PHP Thumbnailer], and have wanted to add them, but at the same time don't as I would prefer not to bloat the class with all sorts of functionality. So I started thinking about how I could provide certain functionality for people that want it, without either simply making it a part of the class (and making it more bloated as a result), or coming up with all sorts of extended classes to maintain and distribute.

His solution was to add functionality dynamically to the class as plugins. Each plugin is defined as its own class (to keep things standardized) and will be included/executed by a base controller class. He includes some sample code showing how to create a basic user object that can store the first and last names of the user in question.

On the ElectricToolBox.com blog there's a quick post looking at method chaining in a Zend Framework application:

Having used the Zend Framework on a couple of projects and spent a lot of time reading the documentation I discovered the use of method chaining. This post looks at how to use method chaining in PHP.

His examples include a comparison between a method-chained Zend_Mail example and a non-chained method with each line augmenting the same object over and over. He also includes the simple-as-pie method that lets you use chaining in your own applications - returning the object itself.

On the PHPBuilder.com site Anthony Corbelli has a new tutorial looking at the differences between using GET and POST in the context of an Ajax-enabled application.

GET is typically used when you simply need to retrieve data and POST is used when you want to change the state of the server (i.e. send/update data on the server). This article will discuss how we use GET and POST methodology in our Ajax applications!

Complete code for his examples is included - both the Javascript and PHP sides. His example handles both GET and POST requests the same way, returning the city and zip information.

Martynas Jusevicius has a new post looking at method overloading in PHP5 - a workaround to make it possible at least.

Method overloading (a feature of object-oriented programing which allows having several class methods with the same name but different signatures) is not implemented in PHP, which is a drawback compared to Java. However, PHP 5 provides a way to imitate overloading by catching calls to "inaccessible methods" with magic method __call.

In his example he uses __call to route the request to the correct version of the constructor (__construct0 or __construct1) based on the number of arguments passed in

On the Tillate Blog today there's a new post from Leo looking at how you can give clients back the control on when your cache refreshes.

We worked hard on the right caching strategy over months now. But there are still caches that do not get invalidated right or are cached too long and we still get complaints from our users. So we decided to integrate a feature that allows certain users to invalidate the cache on the server side. The first idea was to add a link to every page that will append a GET-parameter to the site and then avoid the cache.

He used the apache_request_header function to get the current request's headers and noticed that they included a cache-control header. By changing up this on the client-side, it allows the site visitor to "force" an update to the information if your application pays attention to it.

In his latest post Paul Reinheimer looks at cross-site request forgeries and, despite the best efforts of the PHP security community, how developers still just miss the point in protecting their own code.

So, cross site request forgeries are a pretty common topic these days; they're in almost every security talk, book, site etc. This is okay; they're important [...] Most of the sites, and all of the books I've read demonstrate things correctly, but when it comes to actual implementation, time and time again, I see code that's just wrong.

He looks at two of the "essentials" when it comes to protecting you and your application - comparison (not taking other values of variables into account) and the unpredictable token (not making tokens, like md5 hashes of information, random enough).

Jani Hartikainen has posted a few ideas on cross site request forgeries in a new blog entry, including some methods to help prevent it in your application.

CSRF, or Cross-Site Request Forgery, is a vulnerability very common in websites. [...] This can be dangerous, especially if your admin interface is compromised: There may be a button on the other site which goes to your admin interface and deletes the latest blogpost for example - and you wouldn't want that!

His method is a three-step process for protection - use POST, protect against cross-site scripting and use a CSRF key in the form to help prevent abuse. A simple script is included to show it working and is adapted to work in a controller plugin for the Zend Framework.

In this new post to his blog Stefan Esser looks at cross-site request forgeries and how they can be prevented in PHP 5.3 by two things - the request_order directive in your php.ini and by not using $_REQUEST anymore.

Although PHP 5.3 is still in alpha stage and certain features like the PHAR extension or the whole namespace support are still topics of endless discussions it already contains smaller changes that could improve the security of PHP applications a lot. [...] With request_order it is now possible to control in what order $_REQUEST is created and what variable sources are taken into account. This finally allows removing cookie data from $_REQUEST without removing them from $_COOKIE also.

He explains why the use of $_REQUEST can lead to such problems (and security holes) and notes that its use makes overriding an application's GET or POST values as simple as adding a cookie. There's even a method for creating a Denial of Service attack against a site using $_REQUEST like this. He points to an example similar to this that happened with phpMyAdmin a while back.

His recommendation?

Once PHP 5.3 is out it is recommended for hosters to set request_order to "GP" on all the servers running arbitrary PHP applications to protect applications [and] application developers on the other hand should finally move away from using $_REQUEST for user input.

Fabien Potencier has a new post to the symfony framework's blog today talking about some more of the "little things" they've added to the latest version of the framework.

Symfony 1.2 already comes with a lot of great new features but smaller things also matter a lot. Here is yet another post about small things we have recently added to symfony 1.2.

The list includes the ability to generate a URL in an action using the routing object, new methods in the form object that make it simpler to use in templates and an update to the Phing/Propel interface to help with debugging.