iBlog - Ilia Alshanetsky

The slides from the PHP & Performance tutorial I've given during the Zend's PHP Conference are now up, you can find them at the bottom of my talks page here. To all the people who have gotten up really early in the morning, thanks for attending and hopefully you've found something interesting for yourself during the talk.

Update: Rasmus has kindly pointed out that stripping while drastically reducing the size (basic binary is about 3x smaller), does not actually impact the startup speed in any measurable speed. A quick test with php-cgi from latest CVS appears to confirm this, so unless you want to save disk space at expense of debug symbols, do not strip! Thanks Rasmus.

As you may know PHP 5.2.0 will feature a very capable filtering extension that can be used to easily validate your input via a number of rules which you can find here. What I am interested in hearing is are there any other common types of data collected by PHP forms that would be worth while adding filters for into the extension. My own suggestions would be the phone (US/EU formats) and postal/zip code validators.

So let's hear what you have to say

Brief Disclaimer: Consider this an RFC of sorts, the suggestions if widely supported may not get integrated and any additions will need to have the implicit agreement of all the filter extension developers before being added.

Unless you've been living under a rock you probably know that Firefox 2.0 was released today. Although, it seems that someone one on the Mozilla's team is definitely living in a cavern since the official siteis still linking to FireFox 1.5.

From a developer perspective Firefox 2.0 introduces a number of interesting features, which are explained in detail on the Firefox 2 for developers site . The thing that attracted my attention was the support for OpenSearch standard pioneered by A9 (Amazon), something IE7 also supports. The nature of this feature allows you to "push" your own site's search into the browser's search list for the searchbox, thereby providing a neat and consistent way to find content for the user.

This is surprisingly simple to do as you can tell from the excerpts taken from FUDforum code (yes, the next release will have support for this feature) which you can find at the bottom.

The other very handy addition to Firefox (something Safari had for quite some time) is the integrated spellchecker. However, the spellchecker by-default will only spell check text found within the textarea tag and not offer spelling suggestions for text inside <input type="text">. Fortunately, Firefox provides the means of telling the browser to spell check those as well via the spellcheck="true" attribute that can be added to the input tag or even the encompassing div and span tags. The same tag with the "false" option can be used to prevent spell checking of otherwise checkable form elements. As with the other option, this attribute will be found for relevant input boxes in the next FUDforum release.

Continue reading "Developer notes for FireFox 2.0"

There are many instances where you may want to see what kind of PHP settings other people are using and what better source of this information then the phpinfo() page.

The problem with finding a reliable pool of such pages is that basic search often contaisn many blog, forum, bugs.php.net and alike entries which area copy & paste outputs from users. This maybe fine in some instances, but what if you just want the real phpinfo() pages. The answer is surprisingly simple.

To get the data you need to simply need to search for a element always present on the phpinfo() page such as the "Zend Scripting Language Engine" string and then for a user-agent containing the indexing bot of your favorite search engine. Among the data displayed by the phpinfo() page is a header containing the browser provided User-Agent field, which is always populated by respectable crawlers such as the ones uses by Google and Yahoo. The presence of this value guarantees that the page shown will be an actual page, rather then a copy in paste where the field will be populated by the user's own browser.

Here are the sample search queries for Google and Yahoo!. Continue reading "Reliably locating phpinfo()"

The 5.2.0 release is turning to be quite an adventure, we can't seem to get the bloody thing out. Hopefully RC6 will be the last release candidate, but given that I've said that about the last 3RCs, who knows...

This said, the delays were not entirely unproductive and every time more bugs were fixed and language was generally made better, so it is not all bad. The release snapshots is available here: http://downloads.php.net/ilia/php-5.2.0RC6.tar.bz2 (md5: 5a146c08f85d8535c76fe6219281a06e) and win32 binaries will be made available shortly be Edin.

As always I'd like to ask everyone to give this release a try to make sure no regressions were introduced and to make sure that your applications can still work with this release. If no major issues are uncovered, maybe, just maybe 5.2.0 in a week.

Search engines have for a long time been a good helper of people trying to find sensitive information or vulnerabilities on the web. When you have a few billion documents indexed, it is inevitable some things that should remain private inadvertainly end up in public directories and get indexed, then its just a matter of writing a sufficiently creative search query to find that data.

There are even sites that aggregate "interesting" search queries designed to quickly locate sensetive data such as Google Hacking Database from "Johny" that has queries to find everything from old vulnerable software to credit card numbers, etc...

There have also been attempts to identify things like SQL injection and XSS by locating sites collecting common form of input and then checking to see if said input is not validated. A good example of this can be found on Michael Sutton's blog, who used Google to generate statistics to identify the frequency of SQL injections.

But this approach is does not really show you the full extent of the exploit, just indicates presence of SQL injection, which can then be explored further mostly through trial an error. Well, no more, thanks to Pierre I've discovered a Google's lab project called "Code Search", which as the name suggests indexes publicly available source code. Meaning that now not only can you easily find exploits, but also get the full context of the code allowing for a much nastier exploitation. Let's give it a shot Continue reading "Google Code Search ~= Hacker's best friend?"

After 2 weeks of inaction 5.2.0 final release is finally in sight. A few minutes ago I've released the last (I mean it this time) release candidate of 5.2.0, RC5. If all goes well a week from now 5.2.0 final will be out ready for use. In the meantime I'd like to ask once again that everyone try this RC, which can downloaded from here:
http://downloads.php.net/ilia/php-5.2.0RC5.tar.bz2 (md5sum: 9a7fb788fbfd2beb8ed7aecb0a7d1598)

I don't think you'd be able to find any major issues or regressions in this RC, but if you do certainly let me know, if necessary RC6 is not out of the question.

If you have been monitoring PHP's internal mailing list you probably know that over the last few weeks we've been locked in a stalemate in regard to the API revision of the filter extension brought to light by Dan from our documentation team. This is also the reason why despite this being early October PHP 5.2 is still not out.

Fortunately, after mediation with Derick and Pierre the two protagonists of the filter conundrum a compromise was finally reached. I took Pierre's proposed patch for the filter extension and based on it made a fairly series of adjustments yielding a very clear and flexible API (I hope) that seems to keep everyone happy. The patch was committed late last night and given lack of complaints today, I think we've finally got this issue resolved. YEY!

The only downside, is that my proposal to rename the filter extension to "Ilia' Awesome Filter Extension" was shot-down, with only Tony being in favor, oh well, I guess you can't have it all.

On a related note, since filter issue is now resolved, we can resume with the 5.2 release cycle and I hope to have RC5 out this Thursday to be followed shortly with a final release. On the bright side, the delay allowed us to fix about a dozen bugs and make PHP 5.2 even faster by fixing an inefficiency spotted by Matt W. related to creation of hash tables with known sizes. Continue reading "Filter Extension Revamped (and PHP 5.2 news)"