There is [still] one big piece written in a less than ideal system. Its still PHP, but much more hacked together. It is our backend CMS system for controlling the website. It is painful to use, and we get many complaints all the time about it. [...] on Twitter, I saw a link for a talk Paul M. Jones gave at the Nashville PHP Usergroup. It was entitled: "It Was Like That When I Got Here: Steps Toward Modernizing a Legacy Codebase." I couldn't think of a better title for that talk, nor a better talk to listen to at this very moment.

He mentions the steps he taking to further advance his own project towards a better, non-legacy state including an audit of the current functionality and getting input from users as to which features give them the most pain.

Using these lists to decide what to refactor, we can get the biggest gains for the least amount of work. If we were to rebuild, we would get the smallest gains (if any) of barely having something functional with the greatest effort.

The Symfony2 core team takes security issues very seriously; we have a dedicated procedure to report such issues, and the framework itself tries to give the developer all the features needed to secure his code easily. Thanks to our successful community donation drive, SektionEins performed a security audit on the Symfony2 code earlier this year. The audit is now over and the good news is that the Symfony2 code is pretty solid; only minor problems have been found. They have all been addressed now

Their findings included things like the Request component trusting certain headers, bad regex validation on datetimes, password encoding issues, cookie handling and exception handling issues. Links to the fixes for each are included in the post.

If there is no logging mechanism, then if there's a goof-up in a production environment, you have absolutely no idea what went wrong. The only thing which a support developer can do in this case is to reproduce the issue at the developer end, which sometimes work and sometimes don't.

The look at the types of logging (trace logs, audit logs and user logging/history) and create a simple class that allows flexibility for file location, priority and timstamping. Their script contains a writelog method that does all the work (including pushing it through the PEAR logging class).

I've been playing around with Snapz Pro lately. I originally intended to use it to help spice up some of my talks by offering prepared demos directly in Keynote, but I have also decided that it would be useful to offer various talks and demos to the PHP community.

The first Brain Bulb Webcast is PHP Security Audit HOWTO, a short video of one of my conference talk.

The webcast plays in QuickTime and lasts about 20 minutes with lots of good tips along the way.]]> Wed, 01 Mar 2006 18:09:09 -0600 http://www.phpdeveloper.org/news/4517 http://www.phpdeveloper.org/news/4517 PHPLife from Richard Davey has been posted.

In this weeks