PHP Coalface

Matthew Weier O'Phinney as a new post to his blog today looking at when it comes to working with module boostraps in your Zend Framework applications - an apparently somewhat confusing topic for several developers out there.

In Zend Framework 1.8.0, we added Zend_Application, which is intended to (a) formalize the bootstrapping process, and (b) make it re-usable. One aspect of it was to allow bootstrapping of individual application modules -- which are discrete collections of controllers, views, and models.

He talks briefly about why module boostraps are run on every request (getting into some detail on Zend_Application), how you can properly set up your boostrapping process and how you can use plugins to initialize only the things you might need and, as he openly admits, that there's just not a really good way to handle this sort of module funcionality.

Pablo Viquez has put together something that all of the Windows-based Zend Framework developers might find very useful during their next offline (or online, really) development session - a version of the Zend Framework manual.

As you might now, you can view and download the Zend Framework reference manual from the Zend Framework site and download it from the download section, however what I wanted was the Windows compiled version of it (CHM file). In order to get this version you need to compile the documentation, after running into some small issues, I manage to do it, and to save you some work.

He only had to fix an issue with one XML file to correct some escaping in the files. You can download both the and the files depending on your needs.

With the releases in the PHP 5.x series (5.3 and now a newly branched 5.4), people have been left wondering about PHP 6 and the promised Unicode support it will include. Development on that branch had all but stalled out and things weren't looking too good for the method of introducing full Unicode support to the language. Johannes Schluter has , though - the effort has been restarted and a new approach has been decided on.

Yesterday the stagnation created by the situation has been resolved and it was decided that our trunk in svn will be based on 5.3 and we'll merge features from the old trunk and new features there so that 5.3 will be a true stable branch. The EOL for 5.2 has not yet been defined but I suggest you to really migrate over to 5.3, which , as soon as possible.

Discussion are being made about which type of Unicode support will actually be introduced with a "string class" wrapper gathering some support behind it to provide an alternative to the current string handling.

Ian Christian has an informative new post for the Symfony developers out there. He's figured out a way to with Symfony's admin generator relatively easily, changing the filename option.

When a file is uploaded using sfForm in the admin generator, by default the filename that's used is a random string, which can look bad in URLs. If you want to change this, it's not immediately obvious how - but it is incredibly simple.

The Symfony project does have on the topic, but it's not the easiest to read. It basically boils down to is defining a function in your extended class based on the name of the file where you can change the name however you'd like. Code snippets are included to make the point a bit more clear.

Jani Hartikainen poses an interesting question on his blog today - is it more correct for a function, having failed at its job, to .

You have created a nice, well written function, but you realize you forgot something: The failure case. What should a function do when it fails? There are two schools for this - the "throw an exception" school and the "return an error value" school. But which of these is the correct approach?

He suggests that this debate has stuck around from the time when there weren't exceptions in several popular programming languages and that returning the value was the only valid way. He touches on what an exception condition is (with a few code examples) and situations where each choice might be the right way to go.

A fun bit of trivia for the Joomla users out there from Brian Teeman's blog today - why the and how it could effect your site's security.

Andrew attempted to give the most complete but the truth is the answer is lost in the dim and distant past. There is nothing you can do about it. On every install a superadmin user is created with username "admin" and userid "62".

Since this is a common "feature" of the older Joomla installs, it could potentially be used in a sort of attack on the site. Fortunately, as of the Joomla 1.6 release, the installation allows you to select a username of your own (while still suggesting "admin") with a new change to the user's ID - 42 instead of 61.

Brian Swan has a new post today looking at one way you can protect your web application from potential attack - by filtering input.

How to prevent SQL injection in PHP scripts is probably a topic that doesn't need anything more written about it. [...] However, it is important to have fresh information for new Web developers and I don't necessarily agree with some of the most common suggestions for preventing SQL injection. [...] So, this will be yet another post about preventing SQL injection, but I will offer my 2 cents about what I think is the right way to prevent it.

He explains SQL injections for those that are unsure on the concept with a basic form example and what he thinks is a better way to prevent it than just trying to escape the SQL - bound parameters. These allow you to both filter and protect your application from any would-be attacks that might come your way. He is, of course, using SQL Server so the parameter binding is included in the database functionality. Other databases might have to use something like to accomplish the same kind of thing.

On the Zend Developer Zone there's a new tutorial for those using the Zend Framework (and more specifically the Zend_Auth component) on a way that you can in validating your users.

As I am building my applications, I always try to improve the code I write in some way. Today I thought about the security issues of any PHP application that uses an authenticating system. [...] There is one particular issue that bugged me for some time. The Identity theft - Broken account and session management issue. Why can one so easily still my session id cookie and suddenly gain access to my account in one particular web application?

He shares a class he's developed as a guideline to help your application automatically test to ensure that the information being given by the user is valid. It checks a security level and validates against the user agent and remote IP of the user to ensure they match. These two criteria might not always be the best choices, but it gives you a push in the right direction.

Code is also included to show how to integrate it into your Zend Framework application by loading it into your base controller and using the "hasIdentity" and "hasSecureIdentity" methods to check the user's credentials.

The PHP.net site has posted for the latest PHP version in the PHP 5.3.x series - 5.3.2:

The PHP development team is proud to announce the immediate release of PHP 5.3.2. This is a maintenance release in the 5.3 series, which includes a large number of bug fixes. [...] For users upgrading from PHP 5.2 there is a migration guide available , detailing the changes between those releases and PHP 5.3.

Security/bug fixes included in this release take care of things like:

• Safe_mode validation inside
• A possible open_basedir/safe_mode bypass in sessions
• Added support for SHA-256 and SHA-512 to php's crypt.
• Fixed a bug in the garbage collector that could cause a crash
• Crashing when using ldap_next_reference

For more information on the release and what was fixed see . You can download this release immediately - or .

As mentioned on the today, the latest version in the PHP 5.2 series has been released - .

The PHP development team would like to announce the immediate availability of PHP 5.2.13. This release focuses on improving the stability of the PHP 5.2.x branch with over 40 bug fixes, some of which are security related. All users of PHP 5.2 are encouraged to upgrade to this release.

For more information about the changes included in this release you can check out the or the . As always, you can get this latest version from .