ActionController::RoutingError (uninitialized constant ApplicationController::AuthenticationHelpers)

AuthenticationHelpers happens to be the first module I include from ApplicationController, and it lives in lib/authentication_helpers.rb. After a bid of head-scratching as to why something that has worked for ages and ages in Rails suddenly stopped working (and in between a beta and an RC release, to boot!), I remembered this change in config/application.rb from running rake rails:update:


# Custom directories with classes and modules you want to be autoloadable.
# config.autoload_paths += %W(#{config.root}/extras)


That looked promising, so I uncommented it, changed extras to lib, and bam, problem solved. Life on the edge is an adventure. :)

Though my blog is the last place I announced the project, it’ll be the first place I announce the Ruby gem that goes along with it. :) I just published a gem that uses the Juicer API (via RestClient) and makes it pretty easy to integrate Juicer with a Rails 3 app. I’ve done the hard work of getting the direct-to-s3 upload with swfupload working for you, so all you have to do is make a few tweaks to your model and you have uploads and thumbnails done for you. You can get at the gem (and a sample Rails 3 app) at Github.

We’ll be posting more about Juicer at the Juicer blog, but I imagine I’ll mention things about it here from time to time. :) And hopefully I’ll get around to posting some of the fun code-related things that make up the service.

Having dealt with the pain of Facebook integrations recently, and having really enjoyed using OAuth, I had to dive in. The result is a new Rails Kit! :) The Facebook API Rails Kit gives you a sample Rails app that integrates with Facebook and shows you how to post to a Facebook user’s stream. Check it out — I think you’ll like it. I would have loved to have had this a few months ago. :)

However, since it took a little longer than it should have to do some testing of the app from the console, I thought I’d post this code in case it proves helpful to someone else working on this. My goal was to manually verify that the access control (the before filter) was working properly, so I could email the details on the OAuth endpoint to this other vendor and be reasonably sure it would work well for them. Here’s the code:

access_token = OAuth::RequestToken.new(consumer, request_token.token, db_request_token.token).get_access_token(:oauth_verifier => db_request_token.verifier)
access_token.get('/some/protected/action')


On line 1 I create a new ClientAppliction in my app. This is basically “registering” the other vendor’s app as a application that my users choose to receive access to their data. In other words, this is the same thing that developers do when they register a new application with Twitter when they want to get access to a Twitter user’s account via OAuth, and then the Twitter user can grant access to that registered application. This is the only line in the code that is related to the provider.

Line 3 creates a new consumer, using the key and secret generated by the provider, and line 4 creates a request token that the other vendor (the consumer app) would use to send their user to my site to request permission (line 6). After the user clicks the “grant access” checkbox and submits the form, a new RequestToken is created for the consumer (used in line 10) and optionally redirects back to the consumer app.

On line 14 I get an access token based on the information received from the ResponseToken (or from the redirect, in the real world), which allows the consumer to act in the place of the user, as if the consumer app were logged in as the user. Finally, line 15 loads a protected action from the app that blocks access with either the oauth_required or the login_or_oauth_required before filter.

Of course you’d want to put something like this into a functional test, but it’s nice to be able to see things work in the console, too.

This app originally supported just plain-old users who created an account at the site with a username and password. Then the client requested that I add Facebook Connect as an authentication option. Using the facebooker gem, most of the work was straightforward. If a user chooses the Facebook Connect option when signing up or logging in, a User record is created and a FacebookUser record is associated with that User. The real problem came with trying to log out a Facebook Connect user.

As far as I can tell from the Facebook documentation, if you provide a logout at your site, and someone is logged in via Facebook Connect, you should call the Facebook API to log that user out of Facebook, too. This is done by using either the FB.Connect.logoutAndRedirect or the FB.Connect.logout function in the javascript API. I wanted to send my users to the /logout URL in the application to do some additional cleanup of the User record, and to use facebooker to clear out the Facebook cookies, so the logoutAndRedirect method seemed to be the way to go. Unfortunately, for reasons that I couldn’t immediately figure out, it would work in Safari or Chrome, but not in Firefox.

So, I tried using the logout javascript method as an alternative. It accepts a callback function as an argument (and here’s the key) that gets executed immediately if the Facebook user has no current Facebook session. Even though the logoutAndRedirect method did absolutely nothing (and returned no error) in Firefox, the logout method would call that callback (even though it didn’t log me out of Facebook). This was progress — though I couldn’t log out of Facebook in Firefox with this function, at least I could log out of my app by redirecting to /logout in the callback, and I wouldn’t be immediately logged back in after a page load or two in Safari (which was the problem I was experiencing with just depending on the facebooker methods rather than using the javascript).

The trick that finally sealed the deal and got all browsers working similarly had nothing to do with the app, though… it was a browser setting. Safari had 3rd-party cookies enabled, and Firefox didn’t. Having that setting turned off prevented the logoutAndRedirect method from working as it should, thus preventing the redirect to the /logout URL. Having that setting turned on caused the Facebook cookies to almost immediately come back, when using just the server-side code to do the logout.

To get everybody logged out, then, regardless of cookie settings, the way to do it is to the use FB.connect.logout with a callback function that redirects to /logout. This successfully logs the user out of Facebook if he has third-party cookies enabled, and logs the user out of your app by destroying the current session even if he doesn’t.