Bear Den Designs

Flexible date input and manipulation in javascript with date.js

date.js is a great little JavaScript library that can make your life a lot easier.

If your used to ruby’s date functions then date.js will make you feel right at home.

date.js can:

• Parse strings into dates.
• Add and Subtract time in days,hours,months or years.
• Easily return “x” “day of week” of “month”
• Boolean assertions for day, week, month, year.
• Turn you into a JavaScript ninja.

Note: Some of the syntactic goodies require ‘sugar.js’

Going into the future is no problem for date.js

Interested in this Friday? April of this year?

What about the first friday of april? No Sweat!

Assert any date properties you want.

It can parse just about anything you throw at it.

There are also some fun number functions.

For more reading, checkout: date.js examples

GeoKit stubbing for faster tests

We recently added geocoding to after_save on an address model to keep track of peoples lat/lng, and found that it added substantial time to our tests. The solution? Easy.

Don’t really need to test that geolocating works, I mean.. GeoKit has its own unit tests. So Stub it! Stub it good!

Place this in your test_helper.rb (and inside Test::Unit::TestCase) for tolerable test times.

“This was written for mocha, but its easy to adapt to rspec or flexmock”

  setup :stub_geocoder
  def stub_geocoder
    geocode_payload = GeoKit::GeoLoc.new(:lat => 123.456, :lng => 123.456)
    geocode_payload.success = true
    GeoKit::Geocoders::MultiGeocoder.stubs(:geocode).returns(geocode_payload)
  end

“Just remember to turn it off if you plan to test any features that rely on actual geocoding!”

Solution to: Permission denied to get property XULElement.popupOpen

What’s that firefox? A cryptic error message? Timmy’s drowning at the old mill?!

I came across this rather strange bug while switching from a file input to a combination of SWFUploader and a text field.

Permission denied to get property XULElement.popupOpen

The problem seems to occur when focusing on the input via javascript.

Solution? Easy, Just add this to your text input:

autocomplete=“off”

And then give firefox a nice pop on the head for being a bad fox! Bad Fox! …No!

I hope that saves you some headache and confusion =)

- Your Friendly Neighborhood Hacker

ActiveRecord.update_attributes has_many :security_holes, :through => :unkown_features

Among you railites who have successfully learned rails, watched tutorials, and generally feel comfortable about your abilities: Probably didn’t know there is a little security hole in your app.

It has to deal with update_attributes, has_many relationships, and a method made available on the parent in the relation.

Example:

class User < ActiveRecord::Base
  has_many :groups
end

In your view you have your pretty form with user’s name and other demographics they can enter in their profile. and a ‘save’ button that leads to a call to ‘update_attributes’.

The problem lies in the fact that has_many creates a method off your object called

 user.group_ids= 

Which allows you to pass in an array of ids and create associations en-mass.
the problem is that I can come in with firebug and add my own fields.

<!-- im in your html source adding my inputs -->
<input type="text" name="user[group_ids][]"/>
<input type="text" name="user[group_ids][]"/>
<input type="text" name="user[group_ids][]"/>

After filling those fields and submiting, if you inspect the params hash you will notice:
- “parent” => {…. “association_ids” => [“1”,“2”,“4”]}

And if you check your script/console and check the associations, they will be there assuming you have groups with id’s of 1,2, and 4.

The implications? If you use these groups for any kind of role based access, a user could assume a group with root/super/power user access!

The lesson?

Protect your attributes!

 attr_protected :group_ids 

But! a better idea would be to use:

 attr_accessible :name, :bio, :etc 

I hope this has helped you as much as it did me!

-TheHacker

A Window Into Functional Tests

So like any ruby blooded human, I create functional tests for my rails applications. However, things don’t always go as planned; a redirect instead of a success, but where to?, the assigns is right, but the flash was wrong, etc.

Sometimes you just need a way to peek at what you get back. If you enjoy gouging your eyes out you can do a puts @response or @response.body

A slightly better alternative is to spit the body to a file and preview it in firefox.

    tmpfile = File.new(tmpname = 'tmp/test_page.html', "w")
    tmpfile.puts @response.body
    tmpfile.close
    `firefox #{tmpname}`

Put this after any get, post, etc, and you will get a decent html output of your view (sans stylesheets and valid links) Although nothing is stopping you from outputting to public, running script/server, and viewing it from there.

• If your dealing with redirects, don’t forget about follow_redirect!
• If your crossing controllers, use integration tests =)

It’s not the be all end all of solutions, but it helps for a quick glimpse while fixing tests.
Hope it helps!