futtta's blog » Internet

The state of WP YouTube Lyte (now with fresh Pomplamoose)

frank — Mon, 30 Aug 2010 06:02:53 +0000

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):

				Document Complete			Fully Loaded
	Load Time	First Byte	Start Render	Time	Requests	Bytes In	Time	Requests	Bytes In
First View	1.850s	0.634s	1.330s	1.850s	15	343 KB	5.350s	22	524 KB
Repeat View	1.142s	0.346s	0.497s	1.142s	5	17 KB	2.455s	5	17 KB

And with WP YouTube Lyte (full results here):

				Document Complete			Fully Loaded
	Load Time	First Byte	Start Render	Time	Requests	Bytes In	Time	Requests	Bytes In
First View	1.201s	0.355s	0.974s	1.201s	10	55 KB	2.065s	20	103 KB
Repeat View	0.605s	0.352s	0.473s	0.605s	2	12 KB	1.447s	5	14 KB

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:

Watch this video on YouTube or on Easy Youtube.

Possibly related twitterless twaddle:

Protecting wp-contact-form from spam

frank — Mon, 23 Aug 2010 15:25:33 +0000

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 = '' . $success_msg . '';
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 ''.$results.'
';

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?

Possibly related twitterless twaddle:

Switching back from Froyo to HTC’s Eclair

frank — Fri, 20 Aug 2010 06:08:22 +0000

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:

Watch this video on YouTube or on Easy Youtube.

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.

Possibly related twitterless twaddle:

PHP OAuth extension: trial, error and success

frank — Sun, 08 Aug 2010 22:02:05 +0000

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?

Possibly related twitterless twaddle:

iGoogle Facebook gadget security flaw fixed & explained

frank — Tue, 03 Aug 2010 22:01:33 +0000

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?

Possibly related twitterless twaddle:

WordPress stats oddity

frank — Mon, 02 Aug 2010 05:55:33 +0000

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?

Possibly related twitterless twaddle:

Severe vulnerability in iGoogle Facebook-gagdet

frank — Tue, 27 Jul 2010 21:11:18 +0000

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.

Possibly related twitterless twaddle:

Why I dislike Facebook’s Like widgets

frank — Mon, 26 Jul 2010 15:17:12 +0000

I like Facebook. I like sharing stuff there, I like liking friends’ activities and I like friends sharing and liking my links and posts. But I really, really don’t like Facebook’s Like buttons and similar boxes! Because I see some serious problems with the like button;

The page containing the “like”-widget loads and renders significantly slower (i.e. performance impact)
Facebook can track me visiting this page, even if I don’t click on “Like” (i.e. privacy issue)
When I do click “Like”, I have no way of checking what will be shown on Facebook. And indeed the buttons are already being used to spread spam, malware is expected to be next (i.e. security risk)
“Liking” a page enters me into a relationship with the page owner, allowing them to “publish updates to the user [and] target ads to people who like [their] content” (i.e. 2nd privacy issue, severely aggravated by the security risk)

No, call me old-fashioned, but I’m much more at ease with the normal Facebook share-mechanism;

a simple link, so no performance impact
no contact with Facebook unless clicked on, so tracking of my surfing behavior is not possible
an intermediate screen shows what you’re about to share, meaning a much lower security risk
no forced relationship with the page owner, i.e. “avert 2nd privacy-risk: CHECK”

But as I can’t force site-owners to remove the “Social Widgets”, I can only install something like No FB Tracking to disable the virus that is the Facebook Like-button. And whine about it on my blog, off course.

Possibly related twitterless twaddle:

Over vanalles en nog wat

frank — Thu, 22 Jul 2010 11:18:24 +0000

Een paar kleine ditjes en datjes, het moet hier niet altijd proper uitgewerkt zijn:

Dropbox is tof, maar niet perfect: op Android een file aan je Dropbox toevoegen doet pijn aan het gat en de Windows-versie wilt ook thuis de proxy van het werk gebruiken (auto-detect proxy werkt niet).
WP-YouTube-Lyte zit aan versie 0.4.1, de afmetingen van de player zijn nu configureerbaar. Het ding is al bijna 2300 keer gedownload (cumulatief voor alle versies) en op basis van de downloadcijfers na een release gok ik dat het op een site of 300 geïnstalleerd staat.
Van cijfers gesproken, afgelopen maandag met deze blog de 100.000 pageviews gepasseerd, dank daarvoor anonieme passant.
Ik draai al een week ofzo op Firefox 4 beta1 (zowel op Windows als op Ubuntu), lekker stabiel voor een eerste beta. Tabs on top is inderdaad logisch en html5 video (met WebM) op YouTube lukt nu ook, maar aan de nieuwe theme en add-on manager is nog “wat” werk. Beta2 zou eerstdaags uitkomen, maar het is nog wachten op de grote javascript snelheidswinst (waarmee FF terug dichter bij de concurrentie zou moeten komen).

En nog wat: als het gesprek even stilvalt, vragen mensen niet meer naar het weer, maar naar je mening over de slaagkansen van droomkoppel De Wever & Di Rupo. Ik zeg dan dat ze moeten slagen en dat ze dat zelf ook weten want dat het er anders niet goed uitziet voor onze portemonnee en dan verwijs ik naar een interessant artikel dat ik daarover op Apache las en het gesprek valt weer stil.

Possibly related twitterless twaddle:

Inventing Androids made easy

frank — Mon, 12 Jul 2010 05:18:56 +0000

Google announced “App Inventor for Android“, a Java Web Start based IDE that allows everyone and your mother to create innovative Android-apps by simply dragging & dropping blocks around;

Watch this video on YouTube or on Easy Youtube.

Granted, this isn’t the web-tech approach I was hoping for (just frigging copy/paste Palm HP’s WebOS’s MOJO, will you Google?), but this sure seems like a great leap forward! Now let’s hope people will do more then let their cat purr on our phones.

If you want to play around with App Inventor, you’ll have to apply for access first. While eagerly awaiting an answer from Google, you can already take some pictures of you cat or you could browse the documentation and the tutorials.

Possibly related twitterless twaddle: