Songbird 0.3

Last week we release Songbird 0.3. It’s the release I’ve been working on since I joined the Pioneers of the Inevitable in January. There are a whole lot of improvements in there to various parts of the application – the database engine was rewritten to be faster and more extensible, we added tabs to the browser, etc – but that’s not what’s really cool. What’s really cool is the new Web API we’ve developed.

Flock 1.0

Flock 1.0 has finally shipped.

Almost two and a half years ago I met up with Bart Decrem for coffee in Palo Alto. He was working with Geoffrey Arone to build a company to write a new browser. Bart wasn’t fully clear on exactly what it would look like or exactly what it would do but he believed that it was important to build a web browser that would break new ground in functionality and experience. He showed me a prototype that showed off two pretty amazing features: really simple bookmarking shared bookmarking and the ability to take pieces of web pages and store them for later reuse. I was excited so I quit my job and joined up.

How I set up gitweb

There don’t seem to be any straight-forward documents on how to set up gitweb, the web interface to git repositories. Or at least I couldn’t find any. After failing to get it working a couple of times and then succeeding a couple of times in different ways here’s the recipe I came up with to get what you can see on http://git.ianloic.com/. What I have there is a bunch of git trees I’m following or working on. Perhaps not a bunch, but at least a few.

Installing Ruby Gems in your home directory

I’ve been playing with Ruby in my cheap shared hosting provider. They don’t include everything I need so I had to install Ruby Gems in my home directory. The instructions don’t work. So here’s what I did…

First set up environment variables to tell Ruby and Gems where to find stuff:
export GEM_HOME=$HOME/lib/ruby/gems/1.8
export RUBYLIB=$HOME/lib/ruby:/home/ian/lib/site_ruby/1.8

Download and unpack the Gems source (this is the version I downloaded, you should grab the latest:
wget http://rubyforge.org/frs/download.php/20989/rubygems-0.9.4.tgz
tar xzvf rubygems-0.9.4.tgz
cd rubygems-0.9.4

Run the setup.rb script with the right arguments to install into your home directory:
ruby setup.rb all --prefix=$HOME --siterubyver=$HOME/lib/site_ruby/1.8

This will install the gem command (and a couple of others) into $HOME/bin and the Gems source into $HOME/lib/site_ruby. Gems will be installed into $HOME/lib/ruby/gems/1.8. You should add $HOME/bin to your path. If you want to install it somewhere else replace $HOME with the prefix you’d like to use.

Out with the old, in with the goo(gle)

[flickr-photo:id=28961855,size=m] Some time ago I reworked my home page to feature content from various other sites I post to (blogs, flickr, delicious) by using some JSON tricks to pull in their feeds. I blogged about how to do this with Feedburner’s JSON API, so that my actual page was just static HTML and all the work was done client-side.

Last week I decided to revisit this using Google’s new AJAX feeds API. Feedburner‘s API never seemed to be well supported (it came out of a hackathon) and it forced me to serialize my requests. In the process I neatened up a bunch of the code.

Insecurity is Ruby on Rails Best Practice

Ruby on Rails by default encourages developers to develop insecure web applications. While it’s certainly possible to develop secure sites using the Rails framework you need to be aware of the issues at hand and many technologies that make Rails a powerful easy to use platform will work against you.

Cross Site Request Forgery
CSRF is the new bad guy in web application security. Everyone has worked out how to protect their SQL database from malicious input, and RoR saves you from ever having to worry about this. Cross site scripting attacks are dying and the web community even managed to nip most JSON data leaks in the bud.

Cross Site Request Forgery is very simple. A malicious site asks the user’s browser to carry out an action on a site that the user has an active session on and the victim site carries out that action believing that the user intended that action to occur. In other words the problem arises when a web application relies purely on session cookies to authenticate requests.

OpenID for the mathematically challenged

The other day I got the OpenID bee in my bonnet and grabbed James Walker‘s module and installed it on my server. Actually I grabbed it from CVS, and then discovered that the CVS version is half-ported to some new Drupal 6 form API, so I ended up using the DRUPAL-5 tag.

Anyway, I use Dreamhost which I love for many many reasons (primarilly it’s really cheap and seems to work really well). Unfortunately they don’t build their PHP with BCMath or even GMP, which means my PHP can’t do the hard math that’s required for crypto. Luckily there’s a mode of OpenID that doesn’t require any work on the relaying party side. So I made a small change that allows James’ module to work in this “dumb” mode.

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 […]