Fixing Rails 3.2 tests with Mass Assignment Security errors

In my controller functional tests I typically start off with something like this:

tests/function/photos_controller_test.rb

  setup do
    @photo = Factory(:photo)
  end

  test "should create photo" do
    assert_difference 'Photo.count' do
      xhr :post, :create, photo: @photo.attributes, format: "json"
    end
    assert_response :success
    json = JSON.parse(@response.body)
    assert_equal Photo.last.id, json["id"]
  end

The setup method creates a valid Photo object (using the Factory Girl gem). The test checks that the controller can create and return a valid Photo by passing it the attributes of a valid Photo, and in this case using json. It’s a fairly simple test.

When I upgraded to Rails 3.2, the upgrade guide tells you to update your test environment to “Raise exception on mass assignment protection for Active Record models” by setting “config.active_record.mass_assignment_sanitizer = :strict” in test.rb

So, when I ran my tests, I would see

ActiveModel::MassAssignmentSecurity::Error: Can't mass-assign protected attributes: id, created_at, updated_at

My tests are failing! Oh no! Looks like it isn’t as easy as simply calling .attributes anymore.

Of course, this is the expected behaviour. You don’t pass the id or timestamps as parameters when you submit a form creating a new photo, and neither should you in your functional tests. Using .attributes was just a convenient, but wrong, way of passing the attributes.

Let’s figure out a better way.

I added the following to test_helper.rb:

tests/test_helper.rb

  def unprotected_attributes(obj)
    attributes = {}
    obj._accessible_attributes[:default].each do |attribute|
      attributes[attribute] = obj.send(attribute) unless attribute.blank?
    end
    attributes
  end

This returns a hash of the attributes which aren’t protected, along with their values. For example, it might return something like this:

ruby-1.9.2-p290 :084 > unprotected_attributes(Photo.first)
  Photo Load (0.3ms)  SELECT `photos`.* FROM `photos` LIMIT 1
 => {"photo"=>http://photo_url.com/photo.jpg, "description"=>"My trip to France"} 

And now in my photos_controller_test.rb I update

xhr :post, :create, photo: @photo.attributes, format: "json"

to

xhr :post, :create, photo: unprotected_attributes(@photo), format: "json"

Feel free to comment below with a more elegant solution!

UPDATE

@nzkoz pointed out that I shouldn’t really post every attribute willy nilly, as that’s not what a form does.

Using the above solution, if an attribute is unprotected, but shouldn’t be, I won’t find out about it because the test will still pass.If an attribute is protected, but it shouldn’t be, again, the test will pass.

What I should do is this:

If I want to test that passing a photo and a description created a valid Photo, the test should be

xhr :post, :create, photo: @photo.attributes.slice("photo", "description"), format: "json"

By explicitly stating what I actually want, I can be sure that the tests are doing what I expect.

If an attribute is protected but shouldn’t be, I’ll get the exception and know to fix it.

I should also write a test which explicitly checks that the exception is raised for attributes I know I want to be protected.

Code Review: Understanding Array#sample

I thought it might be a nice idea to dig in to pieces of code that I find interesting, look at the source, and figure out how they work. It’s a good mind exercise, and as a Comp Sci person I should be doing this more often to broaden my knowledge of succinct and inventive ways to write code.

This is an intermittent collection of me going “OMFG look what I just found!!” and then getting my head around things, hopefully helping you do that too. I assume you have a basic knowledge of Ruby and/or Rails and/or programming in general.

The first of this series is Rails’ Array#sample. Before you read any further, head on over to RoR’s documentation for Array#sample. It has an explanation, examples and -yay!- the source. Click [show source] and read over it yourself. See how much insight you can gain before coming back and checking here.

Go on. Don’t cheat!

Done that? Good. Here’s a quick run down:

• It’s an instance method for any Rails Array.

• It takes zero or one arguments, n

• The argument needs to be an integer, or have a .to_int method returning an integer.

• It returns n non-duplicate elements of the array on which you called the method

Here’s my step by step look at the source, with explanations on what’s going on.

 
def sample(n=nil)

This defines a new instance method called sample. It accepts one argument called n which defaults to nil if no argument is given.

    return self[Kernel.rand(size)] if n.nil?

If n is nil (i.e. no argument was given) we get a random value from our array and return it. Kernel.rand(size) returns a random integer between 0 and size, where size is the result of calling the Array instance method called size.

    n = n.to_int

Otherwise we start a whole bunch of tests and assignments to make our variable n one we can use safely. First off, if n isn’t nil then we call the to_int instance method on it, and re-assign it to n.

    rescue Exception => e

Rescue is the Rails way of handling exceptions, like catch in Java. Exception is the super-est super class of exceptions, so rescuing Exception will catch any exception. The exception is given to the subsequent block as a variable e.

        raise TypeError, "Coercion error: #{n.inspect}.to_int => Integer failed:\n(#{e.message})"

In the rescue block we raise our own error (throw in Java). It means that we couldn’t turn n into an integer type, and also shows the exception’s message.

    else

Otherwise, let’s get down to business!

    raise TypeError, "Coercion error: obj.to_int did NOT return an Integer (was #{n.class})" unless n.kind_of? Integer

Still checking that n is O.K. to use, we say unless n is a kind of Integer (i.e. n has an instance method .kind_of? which returns true when passed Integer as an argument) raise a TypeError.

    raise ArgumentError, "negative array size" if n < 0

If n is less than zero return an ArgumentError. Arrays don’t have negative indices, but you already knew that, right?

    n = size if n > size

If n is greater than the size of the array, then make n the size of the array.

Now n is a variable which is an Integer, greater than or equal to 0, and less than or equal to the size of the array.

    result = Array.new(self)

This creates a new Array instance, passing this array instance as an argument. .new(self) returns a new instance which contains copies of whatever is in this array, in the same order. (See Ruby’s Array#new).

    n.times do |i|

This starts a loop which will execute n number of times. It passes each loop an integer i which is the number of iterations executed so far (e.g. i could be 0, 1, 2).

        r = i + Kernel.rand(size - i)

Assign an integer to a variable r. This integer will be between i and the size of the Array, and be a pseudo-random number between i and the size of the array minus i.

If i was 3 and the size of the array was 5 we might have r = 3 + Kernel.rand(5-3) = 3 + 2 = 5

        result[i], result[r] = result[r], result[i]

This is the magic line. This was what made the code so interesting for me - I didn’t know you could assign variables like this.

What it does is swap the values at result[i] and result[r]. e.g.:

result = [1, 2, 3, 4] with i = 1 and r = 3 would return
result = [1, 4, 3, 2]

It just shuffles the elements of result around, n number of times, psuedo-randomly.

    end

    result[n..size] = []

We only want to return n results, sampled from this instance of an Array. Since it’s already shuffled we can just chop the end off result and return that! This line sets the subset of result from index n to the end of the array to an empty array. e.g.:

[1, 2, 3, 4, 5, 6][4..6] = [] becomes [1, 2, 3, 4]

    result

Return result (without needing to say return, as it’s the last bit of code in the method).

end

The end!

Wow! I love the simplicity of this code - once you wrap your head around it.
 
If I’d had come at this problem myself I would have probably started off with an empty array and n times picked a random value from self and taken it out and put it in result. It would have been yuck, involving array resizing and unnecessary bloat. I love the simplicity of just shuffling the variables around.
 
So that’s Array#sample. I hope I didn’t get too much wrong, and I hope you learnt something. Please comment below with corrections, feedback, and with what you might like to see in the next Code Review post.

The perfect complement to LostLookout.com

You’ve lost your camera. It’s on Lost Lookout. If only you had this idea:

…. there’s more ….

Read the rest at http://threesixfivedaysoflove.tumblr.com/post/4981682205

How to assert an HTML attribute does not exist in Rails

Today I was testing a Ruby on Rails form. The values of an input are pre-populated if a user is logged in. That’s easy enough to test:

assert_select “inputSelector[value=?]”, expected_value

This finds the input and looks at its value attribute. Standard stuff.

However it took some Google-rummaging to find out how to assert that when a user is not logged in, there should be no value attribute at all.

assert_select “inputSelector[value=?]”, /.+/, :count => 0

What this says is “the number of occurrences where the value attribute of input contains zero or more characters should be zero”.

You can’t use 

assert_select “inputSelector[value=?]”, 0

because that will look for that input where the value is ‘0’.

You can’t use

assert_select “inputSelector[value=?]”, nil

because assert_select complains about “Expected at least 1 element matching… found 0”

So that’s how I did it. This should apply to any HTML attribute you can select. 

Read more about assert_select at api.rubyonrails.org

Software Development Life Cycles: History and Future

For SWEN301 at Victoria University I had to write an essay/report on “Software Development Life Cycles: History and Future”.

It’s not a terribly exciting essay; most of it is regurgitation to prove I know something. However the bit about forecasting future trends is my own thoughts, and I’d be interested to see what others have to say! 

The due date has passed, so you won’t be helping me cheat or anything :)

Here’s the abstract:

This essay gives an introduction to three software development process models and their future trends. These are Waterfall, V-Model, and Extreme Programming. Its purpose is to identify similarities and differences between them, central themes common to all process models, and forecast trends for future process models. Themes in this essay focus on how process models both enhance and hinder a team’s ability to develop software which satisfies the needs of the customer. I forecast that future models will be modularized, support analysis through measurable processes, and enhance distributed development. Future models will therefore offer more effective solutions to delivering customer satisfaction.

You can read the full thing at http://itsnickmalcolm.com/swen301_essay.pdf

For you SWEN301ers reading this in the future - don’t plagiarise! ಠ_ಠ

Running Rails 3 commands on a Rails 2 box

I was at home last night trying to administer my new website Lost Lookout when I ran into some trouble. I’m using my work’s server (thanks guys!) to host my web app.

The box is, by default, using Rails version 2. My app is Rails version 3. So, when you fire up the terminal/console, you enter something like:

$ RAILS_ENV=production rails console

It acts like rails 2 and makes  new project called console. >(

Super lame.

I spent ages trying to Google the correct command to make it run as if it’s Rails 3. I had it written down at work. Now I’m at work I want to tell the world and myself, for future reference, how to do it:

$ RAILS_ENV=production bundle exec rails console

That simple little bundle exec. It makes the command run in the context of the bundle. Which, for my project, is Rails 3. Voila!

Lost Lookout, my new website

Just before Christmas in 2010 I was on the bus to work. As I was hopping off I saw something lying on the floor. A Phoenix Season Pass.

“Awesome!” I thought. But then the good ole morals kicked in, and I knew I had to return it. But how? All I had was a credit card sized piece of plastic with a name and some barcodes on it.

I turned to Twitter and Facebook. I tweeted that I’d found a season pass, and got a few retweets out of it. But no one knew the owner. I did the same on Facebook, again with no luck.

Surely there’s an easier way to reunite lost items we find with their owners?

Popular Lost and Found websites at the moment are pretty much exclusively for pets. And they’re just huge lists. Ew.

It should be easy to have lost stuff reunited with their owners.

So I hatched an idea. For most of this summer in my spare time I worked on it. Now it’s ready.

*drumroll* *cymbal crash!*

Lost Lookout has arrived!

*applause*

Lost Lookout is the answer for everyone who has lost something or found something and not known what to do. It’s pretty simple. It’s a map. With lost and found stuff on it. That’s it.

The beauty of this is when you lose something and put it on the Lost Lookout map, other web users are able to say “Oh hey, I’m walking past there on my way to work. I’ll keep an eye out for it.” By putting it on Lost Lookout you increase your chances of getting it found.

If you find something, it’s the same deal. Put it on the Lost Lookout map. The owner will hopefully know where they lost something. At least approximately. They will turn to Lost Lookout and see if it has been found yet.

Somewhat ironically the first listing is the jacket I lost last week at uni.

“But wait,” I hear you say, “There’s hardly anyone using that site yet anyway! No one will find you jacket!” Good Point.

Delivering Value to the First Customer

I knew starting out that every customer (user of Lost Lookout) will be playing a waiting game. Humans don’t like waiting. It’s lame.

Lost Lookout has a special time saving feature to help you be proactive. As well as easily tweet/facebook-able listings, Lost Lookout provides the Ready Made Poster feature.

Once you’ve put the item on Lost Lookout you automatically have access to a printable flyer with a photo, map and detachable contact slips. Easy peasy! No need to fire up bloated Word processing programs.

From the moment you start using Lost Lookout, your life is easier.

Where to now?

I’ll actively develop the website and might even add new features if it is in keeping with its simplicity. I think the website could be simplified even further to be honest.

But the main thing will be receiving feedback from customers. That’s you!

Head on over to Lost Lookout, have a play around, (report bugs), but most importantly: keep an eye out for lost stuff near you

Wellingtonians! Be informed, be prepared.

In the wake of February’s earthquake disaster in Christchurch, here are two things I’ve come across to inform Wellington of the dangers we face.

Most people in Wellington know that ‘a big one’ will come at some point, but where is most at risk? What might happen?  If you’re informed, you can (hopefully) be more prepared.

GNS (Institute of Geological and Nuclear Sciences) video on the Wellington fault:

http://www.youtube.com/user/GNSscience#p/u/13/FMBJGS39_bQ

In particular it describes where the fault line runs, and where we can see it in our neighbourhoods. It also has a pretty cool fly over.

Map of at risk public/commerical buildings in Wellington:

http://maps.google.com/?q=http://carlwithak.info/wellington.kml

The ones to look out for here are buildings described as ‘124 served’. This means the building can only withstand a seismic loading at most 33% of what is specified in modern standards.

Building Standards - how strong is strong?

I received an informative email from IPENZ (Institute of Professional Engineers New Zealand) detailing some facts regarding the Christchurch, and modern building standards.

Here’s an excerpt:

Non-residential buildings designed before 1976 were not explicitly required to have ductility incorporated in them. In the early 1980s, the design standard for reinforced concrete was revised significantly to ensure non-brittle behaviour under design-level earthquake loadings, and the strong-columns/weak beams philosophy was introduced so that life safety could be achieved under design-level earthquake shaking.

Buildings are not designed to be earthquake-proof. Two design levels are considered. A building of ordinary importance is designed for a level of shaking that has a 10 % probability of being exceeded in its design life of 50 years.  The design standards are formulated to ensure that life safety is achieved during that shaking, but the building might be an economic write-off because of the damage. It must not collapse at this level. The designer is also required to check that the building does not have damage at a level about 1/6th of this design level. This Serviceability Level is set to correspond with shaking that has a 10% probability of being exceeded in one year. 

To put it another way, The Life Safety design level can be expected to be exceeded on average (over a very long period of time) once every 500 years, and the Serviceability Level once every 20 years.

Note that no mention has been made of earthquake (Richter) Magnitude, as the building responds the same way to shaking that comes from a small close earthquake or a large distant one. 

124 Served - what does it mean?

There are 170 buildings in Wellington who have been served ‘124’ notices.

As said previously, this means it can withstand an earthquake whose strength is under 33% of what modern building standards require.

Modern standards say a building should expect to be shaken above what it can handle without causing loss of life once in every 20 years. 33% of that is 6.6 years. ‘124 served’ buildings can only withstand an earthquake likely to happen, at most, in the next 6.6 years.

The Life Safety design level of those buildings can expect to be exceeded within a period of 165 years. Some of those heritage buildings will be coming towards the end of that period.

There remaining 638 are described ‘Earthquake Prone’. This means the Wellington City Council hasn’t finished its review yet.

Going forward

It’s good to see the Wellington City Council release this kind of data, and hopefully it shows they are being non-complacent about such things.

Having an informed public means we can all deal with disaster that little bit better if when a big one comes.

The lowdown on my Summer ‘Job’

So life’s been pretty busy this past month - I started my awesome new job at Southgate Labs doing web development in Ruby on Rails!

Southgate Labs is Rowan Simpson, Michael Koziarski and Amnon Ben-Orr, and they are top guys in their field. Seriously, it’s a fantastic honour to be working alongside people so well respected in the industry. Check the website for more info.

And let’s not leave out my awesome co-intern, Amanda. She and I were hired through Wellington’s Summer of Tech program. It places students with companies for the summer.

It’s seriously such a sweet placement it’s hard to call it a job. I love waking up and going to work, which is a great blessing!

My first week there was working on two competition entries for Mix and Mash 2010, a competition to creatively use government data.

The results are out, and both of our entries won their categories!

Amanda and I worked on an entry by ourselves - Tax Receipt 2010 shows how big a piece of pie different govt. departments received from the tax you paid. All of us worked on MP Playing Cards, an iPad app which battles MP against MP.

For the tax calculator I did all the programming, which was basically learning how to use jQuery and finding cool plugins to make it look purdy. I also learnt how to make it look sweet on mobile devices. Amanda did the design side of it. I’m really proud of it!

For the MP Playing Cards I worked with Koz on the Rails backend. My biggest part was implementing an API for the iPad app to call. It was a really nice week of getting to know the languages I’ll be using throughout summer.

TV3’s Nightline did a story on Mix and Mash which showcased both our entries. You can watch it at http://www.3news.co.nz/Can-you-make-Govt-data-creative/tabid/368/articleID/190365/Default.aspx

Not sure how much I can say about my project, but it’s reasonably self led. I’ve done the planning, milestones, competitor analysis etc. Now I’m about to finish the first iteration, which is quite exciting. Things are on schedule before Christmas so I must have planned pretty well!

I’ve learnt a lot about developing in Ruby on Rails, and now it’s the little things which are starting to catch me out - the quirks I have to get used to. It’s a really fun language to use and there’s some really nice gems (plugins) to make development a lot easier.

Anyway, Merry Christmas! (Don’t forget the reason for the season, btw).

Your dollar needs to meet my friend Movember

Hello friends, look at that dollar in your wallet, now back to my Movember campaign, now back to that dollar in your wallet, now back to my Movember campaign. Sadly, that dollar isn’t part of my Movember campaign, but if you buy one less coffee and donate it to support the Cancer Society and Mental Health Foundation it could be part of my Movember campaign.

Look down, back up, where are you? You’re on a boat with the men your dol…lar has saved. What’s in your hand, back at me. I have it, it’s the toy of that man’s young child who now has a father for a little longer. Look again, the toy is now the cure to cancer. Anything is possible when your dollar is contributed to my Movember campaign and not given for a coffee. I have a moustache.

Donate at http://nz.movember.com/donate/your-details/member_id/694646/

Please help support men, their families and their friends who are sufferring because of cancer and mental illness.

###########################

About Movember

Each year, Movember, is responsible for the sprouting of moustaches on thousands of men’s faces in New Zealand and around the world, with the sole aim of raising vital funds and awareness for men’s health.

Men sporting Movember moustaches, known as Mo Bros, become walking, talking billboards for the 30 days of November and through their actions and words raise awareness by prompting private and public conversation around the often ignored issue of men’s health.

Supported by the women in their lives, Mo Sistas, Movember Mo Bros raise funds by seeking out sponsorship for their Mo growing efforts. The rules are simple; register online at Movember.com and start the month of Movember clean shaven, before growing a Mo.

Movember is now in its fifth year in New Zealand. The money raised as a result of the Movember campaign is channelled by our men’s health partners into a number of world class and innovative education, research and awareness initiatives. Movember New Zealand collaborates with two men’s health partners – the Cancer Society and the Mental Health Foundation of New Zealand.



The Cancer Society of New Zealand (www.cancernz.org.nz) is the leading organisation dedicated to reducing the incidence of cancer and ensuring the best cancer care for everyone in New Zealand.

The Mental Health Foundation (www.mentalhealth.org.nz) works towards creating a society free from discrimination, where all people enjoy positive mental health and wellbeing.