futtta's blog

Although it has been a few months since I last wrote about my baby WordPress plugin, time did not stand still between version 0.3.0 and 0.5.2; the player size can now be changed in the options-screen, I’ve replaced my newTube html5-hack with Google’s official (yet experimental) new html5-compatible embed code and I started migrating the CSS from the mess that had become the JavaScript-file. And I almost forgot what may be the most important change; I started searching for blogs that use WP-YouTube-Lyte to see how it behaves in the wild. Some of the bugs I discovered that way;

• WordPress has a lousy “the_excerpt”-function which removes script-tags but not the script itself, which caused my JavaScript to be displayed as normal text in excerpts (typically in category-pages). Fixed with some unpleasant CDATA-tinkering.
• Some blogs allow crawlers to see the contents of a directory if no index.* is in place, so e.g. options.php gets indexed with an ugly (but logical) error-message. Fixed with an index.html.
• There’s a lot of themes and some of those have CSS that impacts the way WP YouTube Lyte is displayed. Most issues should be fixed by better CSS for my plugin, but do let me know if you encounter more weird display-problems (especially the controls that are incorrectly positioned).

But with all those changes you might start to wonder if WP-YouTube-Lyte still reduces download size & rendering time substantially, no? So I ran a couple of new tests for this page on my blog (it has 3 embedded YouTube’s) on webpagetest.org (settings: 5 runs on IE7 via Amsterdam, excluding requests to stats.wordpress.com). The difference is … well, judge for yourself (or see below the tables for the summary)

With normal Flash-based embeds (full results here):

And with WP YouTube Lyte (full results here):

Did you see that? Less requests, less data and faster rendering for first and repeat views. Hurray for WP-YouTube-Lyte! But enough with that ego-tripping already, I’ve got an Opera-bug to look into! Or wait, I’ll watch this great new Pomplamoose+Ben Folds+Nick Hornby  videosong first:

Ever since I installed WordPress on my (virtual) server, I’ve been using the WP Contact Form plugin to provide me with simple contact form. The plugin isn’t exactly under active development (Last Updated: 2009-8-28), but it got the job done and I was quite happy with it. Until spammers found the page and started abusing it, that is. There’s a bunch of other Contactform-plugins in the wordpress.org plugins repository, but most of them were either too feature-packed or development for them seemed to have stopped.

I considered adding ReCaptcha at first, but why would I want to put my visitors through such an ordeal; the captcha’s seem to have gotten very difficult to decipher.  Next possibility; implement Akismet (Mollom would have been a great choice as well)? There’s a great Akismet PHP5-class, you just provide your API-key and off you go. But it seemed kind of inefficient to have to do all that with the official Akismet-plugin already in place?

But wait a minute, why not just piggyback on the Akismet-plugin, as the Clean-contact plugin and wp-contactform-akismet did? Keep it simple stupid and so I just copy/pasted the clean_contact_akismet-function from Clean Contact’s code into my wp-content/plugins/wp-contact-form/wp-contactform.php and on line 142 I changed:

mail($recipient, $subject, $fullmsg, $headers);
$results = '<div style="font-weight: bold;">' . $success_msg . '</div>';
echo $results;

into:

$akismet=clean_contact_akismet($msg,$subject,$email,$name);
if (!$akismet) {
mail($recipient, $subject, $fullmsg, $headers);
$results = $success_msg;
} else {
$results = 'If it looks like spam and smells like spam, it must be spam. Leave (or rephrase)!';
}
echo '<div style="font-weight: bold;">'.$results.'</div>';

That was all it took to add Akismet spam-filtering to that KISS-y wp-contact-form plugin. I wonder why this isn’t in the plugin already?

Although I was quite pleased with my Hero after installing HTC’s version of Android 2.1 (in the guise of VillainRom 12), I couldn’t refrain myself from wanting to install Froyo, the latest and greatest version of Android. The guys over at VillainRom provided a great Froyo rom (Froydvillain 1.2) based on the official Android sources and the work of the CyanogenMod team with CM6 and added LauncherPro, a beautiful alternative to HTC’s Sense, to the mix:

After seeing FroydVillain run on the Hero of a daredevil colleague of mine (thanks Thomas!), I swiftly booted my HTC into recovery mode, made a backup of my Eclair-installation and effortlessly slapped FroydVillain on my handset. But now, only 2 days later, I’m back on HTC’s Eclair.

Why? Because of what HTC adds to the mix. Although Froyo + Cyanogen mods + LauncherPro is a fast & slick combination, there were a number of (mostly minor) annoyances which bugged me enough to do a rollback to VillainRom 12 (i.e. HTC’s Eclair).

Some of the quirks that irked me:

• the keyboard seemed a tad more clunky, there’s no button to hide it (the keyboard tends to get in the way sometimes) but most importantly there’s no Dutch dictionary installed meaning no spelling correction and above all no text-prediction
• the new Android-native Exchange mail integration is great, but there’s no indication of new Exchange mails on the Launcherpro homescreen and most importantly it is too easy to accidentally delete a mail (the button is located at the bottom right of the screen!) and there’s no undo or move available
• battery life seemed shorter and there’s no way to disable ‘always-on mobile data‘ (a continuous data-connection doesn’t help battery life)
• the dialer application (you know, to actually call someone) does not search my contacts while typing a number (HTC’s dialer searches both numbers and names, which is a great time-saver)
• in the browser bookmarking is less straightforward (no ‘add bookmark’ in the menu iirc), there’s no ‘reload’ in the main UI (it’s at the right side of the address-bar in HTC’s Eclair)
• the free version of Launcherpro does not come with a calender widget (the “Plus” version does though) and I could not find one to my liking on the Android market
• as I had to re-install my apps, Shazaam didn’t recognize me as an existing user, meaning I lost unlimited tagging

So in spite of increased speed and an overall very nice package, I decided (after having had to run downstairs last night to move that accidentally deleted important mail back to my inbox on my PC) to abandon FroydVillain and switch back to VillainRom 12. I was a little upset with Nandroid spitting out that horrible “Run nandroid-mobile.sh via adb” error, but it turned out that it wisely doesn’t like to have to work on an almost empty battery. After recharging I successfully restored good ole HTC Eclair.

Froyo + LauncherPro is a great combination, but it’s not in the same league as HTC’s polished Eclair builds yet. Thanks for the great job HTC, I’m looking forward to your Desire HD with HTC Froyo (or Gingerbread?) which I’ll probably buy from you next year.

I’ve been experimenting with the PHP OAuth PECL extension over the last few days and initially ran into some small problems getting it to function correctly. So for the sake of making this world wide web an even better place, here are some error-messages you might encounter and what you could do to resolve them:

• “OAuth::getRequestToken() URL file-access is disabled in the server configuration” → the OAuth extension by default uses fopen (streams) to fetch data from the OAuth provider (server), but you’re probably slightly paranoid (or is it security- conscious?) and have allow_url_fopen = 0 in you php.ini. Just change that value to “1″ and reload your webserver and then see …
• “SSL: fatal protocol error“ → OAuth seems to be working fine, but for reasons unknown OAuth insists something fatal just happened. You could ignore this one, or try to lower the error-reporting value or do as I did and decide to use OAuth::setRequestEngine to switch from those doomed streams to almighty Curl, until …
• “setRequestEngine expects parameter to be long, string given” → so you installed (compiled) the OAuth-extension, but you didn’t have that libcurl-dev package installed, did you? No matter how polite you request that Curl-engine, it is just not going to happen unless you install libcurl-dev, and then re-installed OAuth.

And after successfully re-installing OAuth, this time with Curl-support, you could try to build a small application, accessing GMail maybe?

I just received confirmation from the Google Security Team that the bug I discovered in the iGoogle Facebook Gadget which allowed attackers to log into an other user’s Facebook account bypassing all authentication, has been fixed. So now that the hole has been closed, let’s look at what was happening, shall we?

The gadget uses the Facebook’s Javascript API to the connect with Facebook, asking you for permission to access your FB data. In the process of getting that authorization, the gadget exchanges tokens with Facebook, some of which should absolutely be kept safe from prying eyes. And that’s where things went wrong: the gadget had the authentication info in the URL. So if a user of the iGoogle Facebook gadget clicked a link to an external site in the news feed, the request for that page had a referrer that contained all authentication-info.

And that’s exactly what happened on last week, when I spotted this referrer in my blog stats:

http://facebookiggadget.appspot.com/?exp_rpc_js=1&exp_track_js=1&st=c%3Dig%26e%3DAPu7icpJzJJhOouS8TuGegSqFHHI8XHU1r55OllrNbk0ey/aTpkUFx9jPKB/cwgcEZoGfcBuc43x/CuzuEL2cQinYglFvhFWKtlXg6j/JtKC0%252BWsAu3vo/3ZR/WA64J/Fmw1YuUFgT7q&v=fdb2b406636e1f3cff1c5d7e660f59eb&container=ig&view=home&lang=nl&country=BE&up_session=%7B%22uid%22:%221165373488%22, %22session_key%22:%2291d52d2ed5a130fd941b11f1-1175373488%22, %22secret%22:%22fdee68961b3cdee5b51390a4bdeac7a0%22,%22expires%22:0, %22access_token%22:%2283101558C90fd9KfA9KJQh5uT98TqIjxQpzUi4.%22,
%22sig%22:%22dd635ef67af1f59c1c671215076cce10%22%7D&parent=http://google.be&libs=7ndonz73vUA/lib/liberror_tracker.js,iHKb-4mKuMY/lib/librpc.js,vrFMICQBNJo/lib/libcore.js,a5j4V1JuNVE/lib/libsetprefs.js&is_signedin=1&synd=ig&view=home

You can guess what happened when I opened that URL; the iGoogle Facebook gadget initialized using the embedded credentials, automatically logging me in as the guy that was unlucky enough to have clicked the link to my blog.

But how could this vulnerability have been exploited, you may ask? Well, easy enough; create a page that is viral enough for people to share or like  (likespam or even likejacking) and wait for users of the iGoolge Facebook-gadget (there’s over 1 million of them after all) to follow the links, feeding your webserver logfiles with credential-rich referrers.

As Google confirmed this bug indeed has been fixed. The new version of the gadget, which was deployed late last week, does not leak credentials in the referrer-URL any more:

http://facebookiggadget.appspot.com/?lang=en&country=us&.lang=en&.country=us&synd=ig&mid=101&ifpctok=6472409229927695377&exp_rpc_js=1&exp_track_js=1&exp_ids=17259&parent=http://www.google.com&libs=7ndonz73vUA/lib/liberror_tracker.js,iHKb-4mKuMY/lib/librpc.js,vrFMICQBNJo/lib/libcore.js,a5j4V1JuNVE/lib/libsetprefs.js

So if anyone asks me what my good deed for this year was; I helped protect 1 million people’s Facebook accounts from being hacked.

Sounds swell, no?

A couple of months ago I removed Google Analytics from this wee little blog, but I still use the less sophisticated WordPress.com stats plugin to follow up on what is being read around here. Loading the stats-page in my Android-browser is far from optimal (it uses Flash to draw the charts and it is a pretty big page), so I was pleased to read that version 1.3 of WordPress for Android features a stats-section. But the reports don’t work, I just get “No stats data found, please try again later”.

Now while playing around with the stats API over the weekend, I noticed some unusual things:

• “blog_uri=futtta.wordpress.com” works
• “blog_uri=blog.futtta.be” results in “Error: zero rows returned.”

The API also supports blog_id instead of blog_uri and after some digging for blog_id’s I found that they are listed in (the html source of) the blog dropdown-list on your wordpress.com-dashboard stats page. And there the problem became clear: I had two blog_id ‘s for the same blog_uri (blog.futtta.be) and the first one was defunct:

• “blog_id=2184847″ results in “Error: zero rows returned.”
• “blog_id=2185033″ works just fine

As I can’t remove the entry with the faulty blog_id from the Stats DB and as I can’t change the Android WordPress app to use one of multiple blog_id’s instead of the blog_uri, I can’t fix this little bugger myself, so I contacted WordPress Support. But how did I end up with 2 blog_id’s in the database?

I by chance discovered a severe security vulnerability in iGoogle’s Facebook-gadget (more than 1 million users!), which allows an attacker to log into an other user’s Facebook account, bypassing authentication.

I contacted the author and the Google security team and they confirmed there appears to be a problem which they’ll look into. While they do so, I would strongly advise everyone not to use the iGoogle Facebook gadget. Once the hole is closed, I’ll provide more info on how this could be exploited.