When using Rails’ verify method to protect your ActionController actions, you should return a list of the allowed HTTP methods in the response headers.

Let’s say you have an action called update that you want to protect from anything but a POST. I like to do it like this:

Now if someone tries to hit the update action with anything other than a POST, an error message will be displayed and the response headers will contain (among other things):

In my opinion, this is a better way to go than redirecting to another action because the use of an improper HTTP method is most likely the result of either programmer error or malicious intent. By redirecting to another page, you are making it much easier to for somebody to take your site down with a denial of service attack and if it’s a programming error, you’ll locate the problem faster.

You should also make sure that you have a functional test for this behavior:

def test_invalid_update_methods
  [:get, :put, :delete].each do |http_method|
    send http_method, :update
    assert_response 405
    assert_equal 'POST', @response.headers['Allow']
    assert_equal '405 HTTP POST required', @response.body
  end
end

Additional Resources

• HTTP 1.1: Status Code Definitions
• HTTP 1.1: Header Field Definitions
• Rails API Documentation: Verification

Three weeks ago I left the security of my job of the last 8 years to pursue a new career as a freelance consultant/programmer.

I’ve been freelancing part-time for several years and it was always a nice supplement to my income, but I was afraid of going it alone. What if I couldn’t make enough to support my family? What if I’m not good enough? What if I fail and have to go find a job? What will people think of me then?

Earlier this year I came to the realization that there is no reason to fear failing. Would it be the end of the world if I did fail? Hardly. Would I be embarrassed? Probably. But, embarrassed or not, I can always change gears or find another job. I could even give up and just lay around watching TV all day while my wife supports me.

So, now I’m doing what I really love: Developing the best software that I’m able, using Ruby and Ruby on Rails. I also plan to spend more time working on my own software and writing about Ruby and Ruby on Rails. I’m even considering doing some speaking on the subject.

Are you looking for an experienced Ruby or Ruby on Rails developer? Maybe you’re just looking for some mentoring or guidance on a project? Send me an email at keithm at infused.org. I’m always looking for exciting new projects.

New in dbf-0.4.0:

• Support for dBase III style memo files
• Documentation in doc/readme.txt
• Fixed that field lengths were being read as signed integers, when they be should be unsigned
• Fixed skipping over deleted records

Thank you to everybody that submitted patches and test files. Keep ‘em coming.

Update_attributes is not very smart; it will update a record whether or not the hash you pass it contains any changed values. If you aren’t careful, you could end up with a ton of database writes for no reason. Try my update_attributes_if_changed method instead:

module ActiveRecord
  class Base

    def update_attributes_if_changed(hash)
      update_attributes(hash) if needs_update?(hash)
    end

    def needs_update?(hash)
      hash.stringify_keys!
      !attributes.dup.delete_if{|k,v| !hash.key?(k) || hash[k] == v}.empty?
    end

    def write_attributes(hash)
      attributes.merge(hash.stringify_keys)
    end

  end
end

I’ve thrown in a method called write_attributes too. It works just like update_attributes, but it doesn’t automatically save the record.

Yesterday, somebody asked me if it’s possible to format the contents of an input field using the text_field form helper.

I don’t think its documented in the API docs, but you can specify the value to use by passing in a value parameter:

text_field :book, :title, :value => @book.title.upcase