History Meme

Posted on April 25, 2008
Filed Under Uncategorized | Leave a Comment

Seems that this history meme thing is pretty popular at the moment. So without further ado here's mine:

history | awk '{print $2}'| sort | uniq -c | sort -rn | head
103 ss
94 ls
61 svn
55 cd
43 cap
32 sc
19 mysql
18 apps
10 rake
9 seq1

I'd like to make it clear that even though my top hit is a common name for a certain military organisation under the command of a certain fascist dictator, on my MacBook it's a bash alias for

./script/server

That it, for starting Rails apps. I also have sc for starting the Rails console. Anyway, pretty good I reckon. A fair few deploys in there and some rake goodness too.

Advancing with Rails, day 3

Posted on April 25, 2008
Filed Under Rails, Ruby, Web | Leave a Comment

The penultimate day of David Black's 'Advancing with Rails' course covered some of the more technical aspects of Rails application development.

Security

We had quite an extensive review of how you can make your Rails application more secure. Rails now by default ships with the protect_from_forgery option enabled in the ApplicationController. This helps to protect your application from cross-site forgery.

Any request (e.g. form input) to your application that comes without the forgery protection token fails with a InvalidAuthenticityToken error. The token is, by default, submitted as a hidden field in your form.

attr_accessible and attr_protected

One thing I haven't made use of in the past but I really like the look of are the attr_accessible and attr_protected macros.

Using these macros it is possible to whitelist and perhaps more importantly blacklist those attributes that can and cannot be updated. If you had for example a User model with attributes name, hashed_password and nickname you could have the following in your model:


attr_accessible :name, :nickname
attr_protected :hashed_password

This statements mean that whilst it is possible to update the attr_accessible parameters through form input, the attr_protected attributes can only by updated through explicit modification (and not via form/url input).

Preventing SQL injection

This has been covered lots before but I still think it's worth reiterating. When specifying conditions on ActiveRecord functions the conditions should be specified as an array rather than using parameters directly in the query.

An example of a vulnerable query would be something like:

User.find(:all, :conditions => "name = #{params[:name]}")

There are a couple of things wrong here. Firstly, the find method is taking conditions from the params and putting them directly into the query SQL. If someone decided to post a query with some SQL e.g.

DROP TABLE users;

You might find you've had your users tables hosed.

The second problem with this is that queries like this really belong in the model layer of your application. So, a better version of this (potentially) dangerous code would be:


class User < ActiveRecord::Base
  def self.find_by_name(name)
    find(:all, :conditions => ["name = ?", name])
  end
end

Then in your controller you call the function like this:


arfons = User.find_by_name("arfon")

The reason that this method of passing parameters to the query is safer is that Rails sanitises the parameters coming in thus protecting the database from a rogue query.

There was plenty more good stuff on day 3 including routes, URL recognition and REST but as it seems to be taking me an age to write up even the smallest part of the course I'm going to call it quits here…

Advancing with Rails, day 2

Posted on April 14, 2008
Filed Under Rails, Ruby, Web | Leave a Comment

I had hoped to post a daily updates on the rest of the 'Advancing with Rails course the week before last, but alas, life was a little too busy so here's what I particularly enjoyed on day 2.

Rails is all about the request cycle

Your application is basically just sitting there waiting for a request. When you send one, it responds then returns to its resting state. To be honest I'd never really given this much thought but it makes sense.

Your controller is your application

The controller is the thing that directs all of the actions, handing things off to other controllers / querying the model. Controllers have access to the whole application domain, can dip in an out of models as they please.

Redirect vs render

This is something that I'd never fully realised. When you

redirect_to => "action"

in your controller, you're actually starting a new request cycle. Crucially this means that all instance variables are reset. I've often found myself doing something like this in a controller:


def update
  if something
    success
  else
    redirect_to :action => "edit", :id => @item
  end
end

If we were updating an item with a form and there had been an error caught by and ActiveRecord validation, the redirect would stop the error from showing up as the @item instance variable is reset when calling the redirect_to.

An alternative to this is the render method. Instead you can do this:


...
  else
    render :action => "edit"
  end
end

This means that the instance variables are kept the same (i.e. not reset) and so errors would show up properly.

This is one of those things where experience had taught me to use a render rather than a redirect, but again, it was great to have it spelled out and explained fully.

Custom validations

It's possible to define a custom protected method called validate inside your models. Using this method you can add an error message on a particular field. In the case below, returning the error "Looser" if the name field equals "matt".


protected

def validate
  errors.add(:name, "Looser") if name = "matt"
end

Another possibility is to have an 'inline' validation as follows:

validates_format_of :name, :with => some regex here, :message => "I don't think much of that name"

This is a good way of checking the format of a field, for example an email address.

Interestingly, every ActiveRecord object has an errors structure. If object.errors is empty then the object is valid (and will save).

After this we went into some hardcore Ruby hacking, but my eyes are too tired for all that now so more later…

Recently


Categories


Archives