Category Archives: Ruby

Google Images Plugin For Corripio

A simple post this time. Corripio is a program for OS X that lets you easily find album artwork for your music collection. However, it's a bit rough around the edges and its built in web based mechanisms for retrieving this artwork are rather limited and frankly a bit rubbish. I've managed to solve all these issues by writing a plugin to fix its unaccountable lack of support for Google Images.

However, a word to the wise: this is probably against the terms of service, so make sure you only use this plugin for personal use!

#!/usr/bin/ruby
#

require 'net/http'
require 'open-uri'
require 'uri'
require 'cgi'

# Construct a query for good-sized Google images by taking the supplied keywords and adding "album"
query = (ARGV + ["album"]).join(" ")
sizes = ["medium", "large", "xlarge"].join("|")
uri = "http://images.google.co.uk/images?hl=en&q=#{CGI.escape(query)}&imgsz=#{CGI.escape(sizes)}"

source = open(URI.parse(uri)).read.gsub("\r\n", "")

# Look for javascript statements of the form dyn.Img("foo", "bar", "lol", "http://www.example.com/yay.jpg")
matcher = /dyn.Img$$".*?",".*?",".*?","(.*?)"/
matches = source.scan(matcher)

# Push back the best 10 results
matches.first(10).each { |match| puts match.first }

To install the plugin, copy the above code into a new file in ~/Library/Application Support/Corripio/Plugins and make sure it is marked executable. Now, you can drag that file into the Plugins section of the Corripio preference pane and then (optionally) disable the default image search plugins. When you're done the preferences pane should look something like this:

Corripio preference pane

Frustration + Lazyweb = Results

OK, to follow up on my last post about the quirks of XMLHTTPRequest, fuzzyman very kindly provided most of the solution I needed.

What I was trying to accomplish is optional HTTP authentication: that is, a resource logs you in if your credentials are correct, but if they aren't present then it just lets you go on as an anonymous user. This is essential if you are developing, say, a web shop: if you want to offer personalized item selections you need to request login, but if you require authentication just to browse the site you've lost a good LARGE_NUMBER% of your customers right there.

However, as fuzzyman rightly pointed out, most browers do not even bother to send the Authorization header unless they actually get a 401 on a page, even if credentials are explicitly provided (as in my use of XMLHTTPRequest). The solution to this is to "fool" the browser into thinking your site requires authentication by creating a dummy action that just requires authentication. The slight complication is that this action must be in the root directory! If you attempt to create the dummy action in a subdirectory, the browser may only send the authentication information thus forced into it when paths are accessed that appear to be in that directory. This means, for example, that if you have the authenicated action "/sessions/secret" then authorization info will be sent for "/sessions/foo", but will not for "/products/list". Making an action like "/secret" works around this, although it is slightly ugly.

class SecretController < ApplicationController

def index
if authenticated?
render :nothing => true
else
response.headers["WWW-Authenticate"] = 'Basic realm="Controllr"'
render :nothing => true, :status => 401
end
end

end

So then in your user creation view and login view you will have a script block which forces the logged in / newly created user to login. This example is for user creation (hence @user.password) and uses a modified version Prototype (the de-facto Rails JS library) to perform the request. I had to modify Prototype to add support for using the username and password parameters of the underling XMLHTTPRequest object, despite the fact that they are widely supported in practice.

new Ajax.Request("<%= url_for :controller => 'sessions', :action => "secret" %>", {
username: "<%= @user.username %>",
password: "<%= @user.password %>",

method: "get",
asynchronous: true,
onComplete: function() {
window.location = "<%= url_for :action => "index" %>";
}
});

Yes, this does send the username and password in plaintext over the wire :-). However, this is OK since they are sent in the clear during signup anyway. I'm also currently using Basic authentication, which means that upon ANY login the username/password are vulnerable (albeit after Base64 decoding): I will probably change this at some point, but the Digest scheme I should be using requires a bit of server side state to prevent replay attacks so is a little tricker to implement.

Right, I should probably try and get some revision done now :-). If only I could answer on Ruby on Rails instead of complexity theory...

XMLHTTPRequest + Authentication = Frustration

So I just spent the last 2 hours or so of my life buggering around with Ruby on Rails and trying to get it to do a RESTful login (i.e. one using HTTP Authorization headers, as opposed to the normal cookie stuff). There are some nice articles about pulling this feat off, such as here and here: the basic trick is to use XMLHTTPRequest to force the username/password from form fields into the browers authentication cache. However, it seems that if the resource your XMLHTTPRequest is trying to talk to never returns a 401 (Access Denied) then XMLHTTPRequest never feels the need to send the Authorization header at all, even if you specify a username and password for it. I'm really at a loss as to why it has this bizarre behaviour, so I'm really hoping I've misdiagnosed it, but it's looking unlikely.

This afternoon has been my first serious attempt to play with Rails, and the whole thing has been nothing but frustration! As well as the usual the-web-is-crap issues like the above, I've had to contend with documentation that is scattered over the Ruby and Rails websites, when it exists at all! Some of the stuff I've had to use (like the base.send :helper_method call to expose some things neatly to my views) seem vital but don't appear anywhere but as cursory mentions in changelogs. Furthermore, their habit of introducing breaking changes means some code examples I find don't work without some obscure patching, and when things go wrong there is so much framework magic going on I have a hard time debugging it! Hopefully this feeling will fade with time, as lots of other people seem to praise Rails to the heavens, but I can't remember even being this frustrated with a new technology :-).