James Smith

Well, it was about time for an overhaul... my old site was looking increasingly outdated, and it didn't really fulfill what I wanted from it any more, so I've moved over to a new one, using Mephisto. It's deployed on my own virtual server, and is running under Phusion Passenger, the new mod_rails solution for Apache. It's definitely been the easiest Rails installation I've ever done! Not sure how well it would stand up to heavy use, but this site certainly doesn't need to be high-capacity, so it does the job admirably.

The hardest thing about getting the new site up and running was deciphering Mephisto's liquid code. While there is *some* documentation, most of it seems to be out of date and scattered across the net, so it was a bit awkward. I'm sure you can expect a couple of blog posts detailing exactly what I had to do to get the site into a good shape at some point...

I have a need in the Green Thing Rails app to pass in limit and offset parameters to a find query, and these parameters come from the URL. For example:

@examples = Example.find(:all, :limit => params[:limit], :offset => params[:offset])

This works fine, but is vulnerable to dodgy things making their way in through the parameters. Normally, to defend against SQL injection, you would use the array form of :conditions to sanitize the parameters, like so:

@examples = Example.find(:all, :conditions => ["name LIKE ?", params[:name])

This is great for :conditions. However, you can't use it with :limit and :offset, despite the fact that they are just as vulnerable to SQL injection. The trick I came up with is this. :limit and :offset are both integers, so simply force the conversion to an integer before using them (checking for nil first, of course):

@examples = Example.find(:all, :limit => (params[:limit].nil? ? nil : params[:limit].to_i),
                               :offset => (params[:offset].nil? ? nil : params[:offset].to_i))

This means that no nasty SQL can get in, because it won't get through the integer conversion. Simple and effective. Probably blindingly obvious, but I didn't find anything online to point me to this solution while I was looking around for :conditions-style sanitizing, so I thought I'd share.

Of course, if I've missed something glaringly obvious, please let me know ;)

I recently reinstalled my laptop with Fedora Core 6, and when I went to fiddle with my prototype Rails project, I found that nothing worked. I had a bunch of problems, and I thought I'd note down the solutions here, in case anyone else had the same problem. So, forgive me, it's going to be techy for a while.

First, the thing wouldn't connect to the MySQL database at all, claiming that /tmp/mysql.sock didn't exist. Odd. Well, not that odd, in fact, because the MySQL RPM for FC6 creates its socket in /var/lib/mysql/mysql.sock instead of /tmp/mysql.sock. So, the addition of a socket line to config/database.yml and we're off again:

socket: /var/lib/mysql/mysql.sock

Next problem: the thing is now connecting, but when I try to recreate the tables using rake db:migrate, it complains thusly:

Mysql::Error: Lost connection to MySQL server during query: SELECT version FROM schema_info

Bugger. Turns out, after some web research, that Rails has changed to new-style password authentication for MySQL. However, the FC6 MySQL installation hasn't, in order to keep compatibility with older clients. Fair enough. Again, it's a fairly simple fix. I had to change the appropriate setting from 1 to 0 in /etc/my.cnf:

old_passwords=0

I was feeling good at this point, and restarted the MySQL server, ready for my Rails app to spring into life. Alas, no, same problem. However, resetting the MySQL password using mysqladmin sorted it all out, and the thing is now happy.

mysqladmin -u user -p password xxxxx

If you're having similar problems, I hope this helps!