Archive for November 2008

The problem lay where I didn’t expect it – it was Firebug. I was using an alpha version of Firebug, which hadn’t updated itself to the latest version. It was capturing the AJAX POST request going out, but didn’t let the parameters carry through. So, I updated to Firebug 1.2.1, and I’m set. Everything’s jake.

I’m totally losing my mind over this problem, because it seems so simple, and yet I can’t seem to figure it out.

Here’s the situation:

I’ve begun linking up my Rubric Manager UI prototype to the Rails backend. On this UI is a big “Save Changes” button, that implements all of the changes to the Rubric in one shot. That button is linked to a Javascript function called save_changes.

So this seems alright to me. I have to include the “authenticity_token” in my parameters because Rails seems to be using some type of internal request forgery protection.

When I click on “Save Changes”, however, Firebug tells me that the page I POSTED to threw an “InvalidAuthenticityToken” exception. So that’s frustrating – I’m clearly passing the token in my parameters. I created a tiny test form and POSTed to the same ‘modify’ method with the authenticity token as a hidden value, and it worked just fine.

So what gives?

Geofrey helped me get by the InvalidAuthenticityToken problem by inserting the authenticity_token variable into the URL string of the Ajax.Request target:

I’ve been putting off doing functional testing with rails for a while now because of the snag that we couldn’t figure out how to test with authentication. Finally I’ve decided to solve this once and for all and get to the root of the problem. First approach we tried was to explicitly log in using a post request to the login page in the test setup. Of course, it didn’t work as each request I believe is independent of the subsequent requests, at least during functional testing.

The next approach we tried was to go down one level and expose the method that sets the current user for the session, and then call that as a controller function. This made me a bit uneasy because we were making the current user setter public, which could probably mean that it would be exposed as an action that can be exploited. Either way, this approach still didn’t work and was still giving us a 302 redirected status.

We decided to go one more level down and tried then to explicitly set the session hash, which is how we keep track of the current user. One way that I came across was to set the session variable in a request object, that is

or some reason, this didn’t work out either. Finally, it turns out that session variables can be set on every (get/post/put/delete) request made as an optional parameter. Now, each of the request type methods are wrapped with an extra user parameter to make that request on behalf of that user. For example, we now have a get_as method defined as: