iBlog - Ilia Alshanetsky

A few days ago a I noticed an interesting behavior in the session_regenerate_id() function. When it renames the session id it does not remove the old session, leaving it active and potentially usable by a would be hacker. This does not pose a problem if the function is only used during new session create as the means of preventing session fixation, which is the intended use btw. However, it makes it completely useless if used on each session based request to prevent session leakage via HTTP_REFERER and similar, since the previous session id is still usable. It also means that changing the id on “actions” as some scripts to do prevent session theft also is pointless; in fact it doubles the amount of session ids for the same user making it only simpler to assume their identity. Furthermore it means that on every call to the function there is duplication in the number of sessions entries that will hang around until they are considered expired and removed by the garbage collection process.

For this reasons, I have added an optional parameter to session_regenerate_id() in PHP 5.1, if set to true, it will force the session extension to remove the old session on an id change.

A few days ago I read an interesting blog entry on Chris Shifflet's blog about Google Web Accelerator (GWA) and how it affects PHP applications. The purpose of the GWA is to accelerate the web page loading speed and thus improve user experience. This is done through a series of techniques which involve different caching mechanisms, periodically downloading copies of frequently accessed pages and prefetching.

The prefetching works on a basis of a premise that when you load a web page you will not view just this page, but also click of a few links from that page. So, rather then waiting for you to click those links, while you are reading the current page, the browser is prefetching the content of the linked pages in the background. By the time you decide to click on the next link, its content is already sitting in browsers cache and can be loaded instantly. Pretty neat trick, right?

While it is a neat trick, it does present several serious problem that affect both the webmasters and the users themselves. Let's start with the webmasters, since after all that's a bit closer to heart
Continue reading "Google Web Accelerator and the dangers of prefetching"

Finally got around to releasing the next stable release of FUDforum, 2.6.13. For the most part it is the same as RC2, with just a few note worthy changes. The Japanese and Romanian translations were updated, Win32 finally has proper timezone support through a custom subset of timezone values and some more adjustments to the nested category display. The latter seems to have been an ongoing problem throughout the .13 release cycle and I sincerely hope we've finally hammered out all of the possible problems with it.

The upgrade and installation scripts are available at the usual location:
http://fudforum.org/download.php.

On a related note, I am now working on a PDO database driver for the forum. This will allow FUDforum to expand it's database support beyond MySQL and PostgreSQL as well as benefit from an improved API offered by PDO. Many of PDO's convenience functions would significantly simplify the process of retrieving data for certain operations.

One conference is over and another one is already in the works. I've been invited to speak about PHP & Performance at OSCON on August 3rd, 2005. This is my first visit to a non-PHP specific conference as a speaker and I very much look forward to it.