Burning your Drupal feed in two easy steps

[flickr-photo:id=136409681,size=m] FeedBurner provides all kinds of neat stats, but it didn’t seem straight-forward to “burn” my blog feed since I’m using Drupal 5. After a little fiddling I think I’ve got a pretty good idea how to make it work in probably the simplest way possible. In fact, it doesn’t require and Drupal configuration at all.

  1. First I set up a FeedBurner account and burned my feed. The feed Drupal produces for me is: http://ianloic.com/rss.xml. Now when I access http://feeds.feedburner.com/ianloic I get the contents of that feed. It’s pretty simple, but so far nobody is going to see that feed.
  2. Then I simply told Apache to redirect all requests for that feed, except the ones from the FeedBurner bot to my FeedBurner feed. With the slight of hand magic of mod_rewrite this is pretty straight forward. In the root of every Drupal install there’s an .htaccess file containing a bunch of stuff. I just added a few lines to the mod_rewrite.c block of that file:
      # Rewrite rss.xml to http://feeds.feedburner.com/ianloic
      # unless FeedBurner is requesting the feed
      RewriteCond %{HTTP_HOST} ^ianloic\.com$ [NC]
      RewriteCond %{HTTP_USER_AGENT} !FeedBurner.*
      RewriteRule ^rss.xml$ http://feeds.feedburner.com/ianloic [L,R=301]

    This will cause Apache to send a 301 redirect to http://feeds.feedburner.com/ianloic any time anyone requests http://ianloic.com/rss.xml, unless their HTTP User Agent begins with FeedBurner.

  3. Now I’ve got access to all the FeedBurner statistics and fun features. Since I didn’t actually touch the Drupal configuration I’m pretty sure a similar approach can be taken to applying FeedBurner to any feed.

Flickr for Dojo

I’ve been working on a little Dojo based application which talks to Flickr, so I put together a little library which uses Dojo to talk to Flickr using it’s rest JSON interface. Use It’s pretty simple to use, just include the JavaScript file: <script src=”flickr.js”></script> Tell the library what your keys are: flickr.keys(API_KEY, SECRET_KEY); And …

Flickr Authentication Security

[flickr-photo:id=1187679,size=m] Recently Flickr closed a little security hole I found in their API authentication. I was able to convince their servers to hand out a token to me based on a user’s cookies and the API key and secret key of an application the user had used. Then with the JSON form of the Flickr API I had full access to the user’s account.

The there two flaws in Flickr’s security that exposed this problem. The first was that the security is based on the assumption that applications can keep a key secret. This is easy for web applications that make server to server API calls, but for anything that a user downloads and especially open source software it’s impossible to keep the key secret. My experiment used the secret key from Flock which is open source – the secret key can be found in subversion, and the secret key from Flickr’s own MacOS X uploader application which can be easilly extracted from the download from their site. Secondly the Flickr server was giving out new authentication tokens without requiring user approval.

The exploit itself is a little state-machine making a series of Flickr API calls and using one IFRAME. It goes like this:

  • Request a frob (via JSON)
  • Request authentication (via an IFRAME)
  • Request the auth token (via JSON)
  • Do evil (via JSON)

In my case the evil consisted of posting a comment on the user’s most recent photo.

The security hole is now closed, but if you’re interested in seeing how to access the Flickr API entirely from JavaScript in a web page take a look at the attached exploit. You’ll also need the MD5 library.

Rules of RDF

[flickr-photo:id=100583394,size=m] At Flock I’ve become the RDF expert. It turns out, in the context of building on the Mozilla platform RDF can be a really flexible, advanced and performant way of modelling data and binding it to ui, however it can be very confusing. There’s some rules I’ve found come in handy:

  1. There are no nodes. There are only arcs. Nodes only exist in terms of being the source or target of an arc.
  2. There are no arcs. We all agree to interpret RDF triples as a directed graph, but really, they’re just triples, just statements.
  3. There is no XML. Most of the time when we see a representation of RDF triples its in a serialized XML form. There are many different, valid ways to express the same RDF graph as XML. The tree of the XML document doesn’t match the RDF graph (usually). Don’t try to treat RDF as XML.

I originally posted this in my livejournal but it didn’t make sense to most of my non-technical readers, and probably not much sense to most of my technical readers. Hence this blog.