Thanks to a number of useful tutorials over at gotoAndLearn() I was introduced to sound spectrums, bitmap filters and creating packages/classes in AS3.0. Of course I had to test myself to see if I had actually learned something. A music visualisation was the result!

Here is what it looks like (if the SWF file is buggy, please tell me how much I suck).

(Please open the article to see the flash file or player.)

What it does is actually quite simple (once you’ve completed the previously mentioned tutorials, that is). Every time a frame is rendered it computes the sound spectrum. Flash has a function that does the comlicated stuff and then returns a set of values which describe how the sound is distributed in the frequency spectrum. Basically the same thing as those ‘jumping bars’ in your media player (or stereo). The visualisation plots this data on a bitmap object, which is then blurred and scrolled up depending on the overall volume. The process repeats itself over and over, which results in a smoke effect. Variations in volume usually create nice puffs of smoke.

I thought this was quite an interesting little project, so I created an ActionScript class which makes the visualisation easy to reuse in other Flash applications. Admittedly, this is my first well-structured ActionScript code ever. Please have a look at it and then proceed to critise my attempt at programming in the comments.

If you happen to like my creation and want to put it to good use, you can download the AS3.0 package. You are free to use and modify it without any limitations, but please let me know in case it’s a public project.

The music in the demo was made by PriZm at OC ReMix. A great website by the way.

You write:

PHP does:

Why does this matter? The manual knows the answer.

On another note: I have been working on a new theme for a while now. It’s probably going to be my best one yet, but I’ll let you judge about that. I am also developing a WordPress plugin at the moment, it will be released when I launch the theme.

Symfony was chosen for, as far as I am concerned, no apparent reason. But I think it came to my attention due to its growing popularity. Anyway, Symfony has a number of features that are not present in most of the other frameworks.

First of all, Javascript integration. Symfony allows you to enhance your application with Javascript, using mostly PHP!. AJAX is also pretty straightforward and Prototype is part of the package.
Furthermore, there are a few useful generators. The most notable is the admin generator.

Besides these features, Symfony has all the conveniences you would expect from a framework. It can really speed up a project once you know how it all works. I am currently in the process of doing just that, learning how it works. This is my first time actually using a framework, though, but I got the hang of it quite fast. I do have to look up all of the built-in functions, which is slightly annoying (Symfony’s reference documentation is not as good as, for example, PHP’s).

By the way, if you like using jEdit, like I do, there are some nice tips on how to use it with Symfony. Those tips should be useful for almost any framework, though.

Since the release of Wordpress 2.0, a pesky bug has been annoying several bloggers. The nice AJAX effects in the administrator panel stopped working; even a fully privileged user would receive a “You don’t have permission to do that” message when trying to add or remove categories, posts and more.

The Wordpress developers are aware of this bug, but the ticket has recently been moved to milestone 2.4. Which basically means we bloggers will have to wait another few months for an official fix.

So far, it has been unclear as to what is causing this problem. I recently upgraded to Wordpress version 2.2 (many important bugs have been fixed, I recommend it) but I was disappointed to find out that the AJAX problem was still there. That’s when I decided to check the root of this bug myself.

Suhosin

Suhosin is a patch for PHP that hardens it against a wide range of web attacks. It’s got a truly amazing set of precautions for problems of which you didn’t even know they existed.

One of its features is cookie encryption. This basically encrypts the cookie using both server and client specific information (a custom key, user agent and more) before sending it to the client. This feature is useful, because if some malicious code on the client-side (XSS is most common) manages to get a hold of the cookie it can not do anything with it.

In addition to encrypting the cookie before sending it to the client, Suhosin will also decrypt cookies it receives so you can use it in PHP without problems.

Or can we…?

All of the AJAX-powered actions performed in the Wordpress admin panel go to one script: /wp-admin/admin-ajax.php
The first thing this script does is calling the function check_ajax_referer() (located in /wp-includes/pluggable.php).
This is what the function looks like:

function check_ajax_referer() {
	$cookie = explode('; ', urldecode(empty($_POST['cookie']) ? $_GET['cookie'] : $_POST['cookie'])); // AJAX scripts must pass cookie=document.cookie
	foreach ( $cookie as $tasty ) {
		if ( false !== strpos($tasty, USER_COOKIE) )
			$user = substr(strstr($tasty, '='), 1);
		if ( false !== strpos($tasty, PASS_COOKIE) )
			$pass = substr(strstr($tasty, '='), 1);
	}
	if ( !sp_login( $user, $pass, true ) )
		die('-1');
	do_action('check_ajax_referer');
}

As you can see, Wordpress avoids using the HTTP Cookie header for AJAX requests (it’s even mentioned in the comment). Instead, the cookie is appended to the request data.This is done, of course, on the client side using Javascript.

When document.cookie is appended to the request, there is still no problem. The Cookie header and the document.cookie are practically the same. But once the request arrives at the server, Suhosin will only decrypt the Cookie. Not the appended document.cookie, because it is not recognised as a cookie at all (it’s just an encoded variable).

So when Wordpress reads the cookie from the request data, it actually reads the encrypted cookie. And you can’t log in with an encrypted cookie, so you are denied permission.

There is a workaround

Fortunately, most browsers (as far as I know) also send the Cookie header. Suhosin flawlessly decrypts the data contained in this header and puts everything in the $_COOKIE variable.

I am not really sure why the Wordpress developers chose to send cookies via the request body, but until they come up with a better fix for this problem, I am providing the following workaround:

function check_ajax_referer() {
	// Suhosin workaround
	$dough = ini_get('suhosin.cookie.encrypt');
	if ( 1 == $dough || 'On' == $dough || 'on' == $dough ) {
		$user = $_COOKIE[USER_COOKIE];
		$pass = $_COOKIE[PASS_COOKIE];
	} else {
		$cookie = explode('; ', urldecode(empty($_POST['cookie']) ? $_GET['cookie'] : $_POST['cookie'])); // AJAX scripts must pass cookie=document.cookie
		foreach ( $cookie as $tasty ) {
			if ( false !== strpos($tasty, USER_COOKIE) )
				$user = substr(strstr($tasty, '='), 1);
			if ( false !== strpos($tasty, PASS_COOKIE) )
				$pass = substr(strstr($tasty, '='), 1);
		}
	}
	if ( !sp_login( $user, $pass, true ) )
		die('-1');
	do_action('check_ajax_referer');
}

This can be applied to any Wordpress installation. Servers without Suhosin will run Wordpress the regular way. Servers with Suhosin cookie encryption enabled will make Wordpress fall back to using the standard cookie.

I might look into writing a PHP function that simulates Suhosin cookie decryption. This will allow Wordpress to use the cookie in the request in both cases. Unfortunately, I was unable to find sufficient information for this.

Patch for Wordpress 2.2

I created a patch file for Wordpress 2.2. It must be applied to /wp-includes/pluggable.php.

Download the file.
Linux users can patch using:
$ patch /path/to/wp-includes/pluggable.php /path/to/pluggable.diff
Windows users can download GNU patch for Windows. And run it from the Command line interface:

C:\path\to\patch.exe \path\to\wp-includes\pluggable.php \path\to\pluggable.diff

I recently wrote a quick and dirty script that retrieves some useful information from the PHP manual docbook files. It parses the function reference documents, to be precise, and it compiles the data into a ‘convenient’ XML file.

The XML file was for someone who wanted to integrate PHP function lookup into his IRC bot. But other than that, I have no particular use for it. So might as well publish it on the blog.

The file is here. I suggest not clicking that link, unless you want your browser to render 1.5 MB of XML data. Download it some other way, instead.

The documentation is copyrighted by the PHP Documentation Group, but you are free to use it under the terms of the Open Documentation License. Have fun!

You might think the browser is the weak link here, because it doesn’t handle the cookie correctly. That is true, but apparently it is difficult to flawlessly apply the same origin policy. I might be wrong though, but it doesn’t really matter for now, because this article focuses on something else.

The server side application at site A could have been protected against the attack. In this article, I will highlight a few methods that could make the process safer. Airtight sessions.

As developers of website applications, we will have to avoid relying on cookie data contained in the HTTP Cookie header when performing certain actions. These certain actions are basically the ones that require authentication (e.g.. changing user preferences, making a blog post, digging a story, etc.)
There are two ways in which this can occur: 1) using an HTML form (with POST data) and 2) using the XMLHttpRequest object. The difference is that the latter uses JavaScript and the first does not (or does not have to, at least).
We’ll have a look at the HTML form scenario first.

The HTML form way

The following form allows an authenticated user to change his or her email address (just try to imagine it, if you don’t agree).
It is generated by a PHP script (doesn’t matter for now, but will be useful later),

The relevant part of the PHP script that takes care of this form (change_email.php) looks like this:

Note that the user is authenticated by means of the session variable logged_in. The session ID is, of course, obtained via a cookie.

We don’t want this, because the cookie might not be safe. Instead, we will use a custom solution. (There may be other possibilities to make this form safer, but I will demonstrate just one.)
To avoid using a cookie, we will make the session ID part of the form. The form code snippet will look like this:

When the form is submitted, it will also pass the session ID. Easy, right?

Now on to the change_email.php script. We must tell the session handler that we want to use the POSTed session ID instead of the one in the cookie (which is the default).
The relevant part is slightly rewritten:

Lines 2 through 6 make sure the POST request is handled using the session that was set in the form. Line 4 may seem kind of useless, but it prevents an E_NOTICE from being triggered (it’s become a habit of mine to code like this…)
The session_id() function allows us to change the session ID manually before starting the session.

This method should stop malicious JavaScript on external sites from abusing your cookies.

The XMLHttpRequest way

Imagine the previous situation of changing an email address, but then in AJAX style. I am not going into detail regarding the usage of the XMLHttpRequest object, because there are a bunch of frameworks that all work a bit differently.
Just keep the following points in mind:

• The request method is POST (the recommended method for this kind of stuff, by the way)
• The server side file is the same as the last version of change_email.php

So, basically, you will need to add the session ID cookie to the POST data. Luckily, you can use JavaScript to extract the ID from the existing cookies:

On line 14, PHPSESSID is the name of the session. It is the default, but if you use a different one, you should keep that in mind. (You can use the session_name() function to find it out.)

This code works because document.cookie is only ‘allowed to look at’ cookies that are associated with the current document (so external sites don’t stand a chance).

Conclusion

Cookies are a nice means of keeping sessions going. But when users of your web application perform sensitive tasks, you should not simply rely on a cookie for authentication.
The increasing possibilities of JavaScript can greatly enhance the usability of your application, but it also makes it harder for the browser (but also the developer) to keep things secure. Therefore, make sure sessions are airtight whenever there is interaction between the client and the server.

This is my first real article here, so if I forgot to mention basic things or something else, please tell me.

On a side-note, ming doesn’t seem to work very well with PHP4. However, this is not a problem because the LLP servers use a technology that allows you to use PHP5 (or even 6) whenever you like.

You can see an on-site example of a ‘ming script’ here.
Or, if you are interested in seeing more cool stuff, there is a large list of examples here.

Anyway, I think ming is a really nice extra.

Edit: Forget what I just said about PHP5. Ming works fine with PHP4 too now. Thanks, Trel!