Code Iteratively » software

Upgrading your Authlogic Gem for Rails3

Christopher Gooley — Fri, 03 Sep 2010 08:45:17 +0000

If you’re using Authlogic in Rails3 (or if you’re upgrading your existing app from 2.3.8 to Rails3) you really need to be using the rails3 branch of the Authlogic gem. If you’re using Bundler, this is super-easy because you just need to update your Gemfile.

In your Gemfile, update the authlogic line to be:

gem 'authlogic', :git => 'git://github.com/odorcicd/authlogic.git', :branch => 'rails3'

Now you should run $ bundle install to grab the new gem. Then, there are just a few more deprecated things in Rails3 that you’ll need to change in your upgraded app. I’ll try to enumerate here from memory, so please forgive me if I forget something.

First, you need to update your ApplicationController because #requesturi is outdated. Replace it with #fullpath:

def store_location
  session[:return_to] = request.fullpath
end

Second, you need to drop the filter_parameter_logging setting from your ApplicationController because it’s now handled in the new application.rb file. Just remember to add the :password_confirmation field to the default array like so:

# Configure sensitive parameters which will be filtered from the log file.
config.filter_parameters += [:password, :password_confirmation]

Third, if your migration script (or the steps you followed manually) didn’t get rid of the /config/initializers/cookie_verification_secret.rb file, delete it now. Cookie secrets are now handled in the /config/initializers/secret_token.rb file.

Fourth, the f.error_message construct isn’t available anymore in core rails, so you should take this opportunity to create your own better more customizable error messages. If you really really want to keep using f.error_message you can install the dynamic_form plugin, but don’t do that. Railscast.com did a very nice explanation of how to create your own shared _error_messages.html.erb view (along with some other validation-related stuff.)

Finally, you need to make sure your generated pages include the csrf_meta_tag. Check out my previous post if you’re getting an InvalidAuthenticityToken error when you hit the Logout link.

That should be all you need to do to have Authlogic working in Rails3 without deprecated warnings.

InvalidAuthenticityToken on Logout when using Authlogic

Christopher Gooley — Fri, 03 Sep 2010 08:07:46 +0000

This one took me a while to debug. When upgrading my existing application to Rails 3 almost everything was working fine except whenever I would click the Logout link I would get an error because Rails couldn’t verify that the UserSessionsController#destroy request was valid from my app.

This is the error message shown:
ActionController::InvalidAuthenticityToken in User sessionsController#destroy

actionpack (3.0.0) lib/action_controller/metal/ request_forgery_protection.rb:96:in `verify_authenticity_token'

And the solution is simple, you just need to add the new csrf_meta_tag helper to your generated page (probably in the /views/layouts/application.html.erb file).

...

  
  Some Title
  <%= stylesheet_link_tag :all %>
  <%= javascript_include_tag :defaults %>
  <%= csrf_meta_tag %>

...

Line 7 is the one you care about and need to have in your html.erb file.

This helper includes the appropriate meta tags which make the authenticity_token available to the handleMethod javascript function. In Rails3, links generated with the link_to helper which use a :method other than GET get passed through that handleMethod function in rails.js. That function creates a temporary form, sets some parameters and submits it. And if you’re using protect_from_forgery (you should be) all non-GET requests are checked to prevent Cross Site Request Forgery (CSRF). So, if those meta tags don’t exist on your page, the handleMethod function doesn’t know what your authenticity_token is, and the request will be rejected with the error above.

Line 5 below is an example of my main nav logout link that was causing the problem when clicked. No change was required to this code after doing the above fix.

<% if !current_user %>
  <%= link_to "Log In", new_user_session_path %> |
  <%= link_to "Register", new_account_path %> |
<% else %>
  <%= link_to "Logout", user_session_path, :method => :delete %> |
<% end %>

This isn’t specific to Authlogic’s logout click – any time you are using link_to now in Rails3 with non-GET methods, it uses unobtrusive javascript. And if you’re missing the csrf_meta_tag helper, any unobtrusive javascript posts will fail to validate.

Coming Soon: Earbits Radio iPhone App

Christopher Gooley — Thu, 02 Sep 2010 03:12:45 +0000

Earbits is a new 24×7 commercial-free, subscription-free free internet radio service that just launched last Friday. Once it’s fully baked, it’s going to have some really cool artist discovery tools and great utilities for bands who want to get their music heard.

I’ve been involved in the minor capacity of building the actual player used on the website and for embedded players on partner websites. It’s been a nice refresher of using my javascript skills. And now, I’m expanding my role into building the first mobile Earbits app for the iPhone. Since I’ve been trying to learn Ruby on Rails over the past week or so, I decided that I might as well also try and learn Objective-C and that whole mess too.

Keeps life interesting. But here’s the teaser shot taken right after the first time I actually deployed the radio app to my iPhone.

Hope to have a beta version done in a week or so, depending on API availability, and get it into the App Store sometime in September.

A User Friend Relationship Model in Rails

Christopher Gooley — Wed, 01 Sep 2010 03:30:22 +0000

In building my first Ruby on Rails app, I needed to create a facebook / social-networking style friend relationship between users. The simple requirements were that it the friendship should require approval (e.g. a friend request followed by an accept or ignore) and it should be lightweight (not using two records for a single relationship).

This method and code is inspired by two blog posts, which got me started but neither of which really fulfilled my complete requirement. The first used two records per friendship and the second was a twitter-style friend/follower without the approval process.

So, here I break down my Friendship model which hopefully you will find useful and/or insightful as a complete solution or a starting point for your own implementation.

First step is to generate a new model that we’ll call Friendship. A Friendship will connect two users, tracking who made the request, who the friend is, and whether the request has been approved. So we generate it like so:

$ script/generate model Friendship user_id:integer friend_id:integer approved:boolean

This will create the db migration script and the app/models/friendship.rb file which we’re going to edit to include relationships to the User model. When first created, the Friendship model will be mostly empty so we need to add two lines.

class Friendship < ActiveRecord::Base
  belongs_to :user
  belongs_to :friend, :class_name => "User", :foreign_key => "friend_id"
end

The first line is obviously creating a relationship to the User model, but the second line is a little more complex. It also needs to create a relationship to the User model (there isn’t a Friend model) but we want to refer to this as the friend. So we have to specify both the :class_name and the :foreign_key so that Rails knows how to hook up this :friend field to actual models.

Now that we have a Friendship, we need to configure the User model to allow for these self-referential relationship through the Friendship model. Before we hit the code, let’s walk through the concepts here that define the state of friendships and friends.

A friendship is a two-way relationship which is initiated by one user and approved by the other user. So, we have two states of a friendship (not-approved-yet or approved) and we have two directions of friendship relative to the current user: friendships requested by the current user (we’ll call these “direct” friendships), and friendships requested to the current user (we’ll call these “inverse” friendships).

So using this terminology, we have 4 possible states of Friendship:
1) direct approved
2) indirect approved
3) direct not-approved
4) indirect not-approved

States #1 and #2 are simply what we will be calling “friends” – they are approved relationships, no matter the direction. Because we don’t care who requested the friendship once it’s approved, we will group these together.

State #3 is what we call “pending friends” – other users whom the current user has requested to be friends with and which are awaiting the other user’s approval. These are out of the control of the current user, and just waiting to be approved or rejected.

State #4 is what we’ll call “requested friends” – other users who have requested that the current user be their friend, and are awaiting the current user’s approval. These are the actionable items for the current user to approve. Ignoring a friend request simply deletes the non-approved Friendship, which is the Facebook method (doesn’t tell the other person they were rejected, but allows them to send another request if they want.)

Now that we have that groundwork, here is the User model:

class User < ActiveRecord::Base
  [...]
  has_many :friendships
  has_many :inverse_friendships, :class_name => "Friendship", :foreign_key => "friend_id"
  has_many :direct_friends, :through => :friendships, :conditions => "approved = true", :source => :friend
  has_many :inverse_friends, :through => :inverse_friendships, :conditions => "approved = true", :source => :user

  has_many :pending_friends, :through => :friendships, :conditions => "approved = false", :foreign_key => "user_id", :source => :user
  has_many :requested_friendships, :class_name => "Friendship", :foreign_key => "friend_id", :conditions => "approved = false"

  def friends
    direct_friends | inverse_friends
  end
  [...]
end

The first two lines are pretty self-explanatory as the first references our “direct” Friendships and the second our “inverse” Friendships which we’ll be using as the basis of all of our friend lists. Lines 5 and 6 simply create our direct and inverse friend lists, only looking at friendships which have been approved. These are states #1 and #2 from our discussion above and are complete, approved bi-directional friends lists.

Line 8 here creates the list of pending friends (state #3 above) by looking for direct friendships which have not been approved. Then finally in line 9 we handle state #4 which are the “requested friendship” waiting for us to approve them, by taking all the non-approved Friendships where the current user is the target of the request (which is why we specify the foreign_key of “friend_id”).

And finally, because it would be a hassle to deal with two lists of approved friends, we create a method to simply combine them under the name of “friends”, in lines 11-13.

That’s it! You should be able to create and manage facebook-style friend requests now.

I’m not going to cover creation of the Friendship controller here in this post, but I may in the future if people would find it helpful. In short, the controller needs to handle just five actions: index, create, approve, ignore, delete. In my implementation, all actions except for index are used only for ajax calls through link_to_remote, so they’re pretty lightweight.

Updated: the direct_friends line in the User model above was incorrectly using “:source => :user” when it should be “:source => :friend” so that the returned models are the Friends you requested, not yourself the requestor.

Annoying Zune Behavior – Ordering “By Rating”

Christopher Gooley — Sun, 29 Aug 2010 19:27:28 +0000

I want to sort my music “By Rating” in the Zune media player software. This is natural. But what’s wrong with this track order here?

Yeah, the software puts the songs which have ratings above the songs without ratings, which in itself isn’t a bad idea. But this means that if you just start playing down the list of your favorite songs right after your favorite songs it’s going to play the songs you hate the most. Then it continues with the rest of your library in alphabetical order.

Come on, Microsoft… you can do better. Just put the most hated tracks at the bottom of the playlist when I sort by rating.

Rails Deployment: Engine Yard or Heroku?

Christopher Gooley — Sun, 29 Aug 2010 17:46:53 +0000

As I’m thinking about beta launching my first Rails app, I need to decide how to do the deploy. Heroku and Engine Yard stand out as the most popular hosts, from what I see. Heroku also has a free option, which appeals to me. Is one much better than the other?

Long-term, I will probably host the app myself at my colo, but to keep things simple at first I don’t want to learn the intricacies of Rails hosting right now…

Chart: A Very Productive Evening

Christopher Gooley — Sat, 28 Aug 2010 11:22:17 +0000

This is what learning a new language looks like: 50% time writing code, 25% time using chrome for research, and 10% time in firefox running and debugging the app.

Clipped from RescueTime which is a fantastic freemium app that tracks everything you do on all of your computers and then does analysis of how you spend your time.

Pretty cool, huh?

Learning Rails – Day II

Christopher Gooley — Sat, 28 Aug 2010 10:50:06 +0000

Well, I spent the second half of today (and >4 hours at Farmer Boys) working on my Whirlfood project in Rails and made a surprising amount of progress. Took some time to start to get used to the Rails methodology and the Ruby language syntax, but I think I’m in pretty good shape now.

Got to admit, I’m starting to like Rails for rapid development. After 2 days, I feel like I can build a simple web app almost as quickly as I can using C#. Which completely amazes me. Of course, there are lots of complex things and specialized functions that I still don’t know how to do in Rails, but still, I’m pretty stunned. In a good way.

I’ve gotten pretty comfortable using generators (a great idea) and then writing my own MVC stuff and doing custom db:migrate scripts to build models with complex relationships. Got the site set up using the Authlogic plugin to handle user sessions, registration and authentication. Used OAuth to write the page flow system to get the tokens and then store them as part of the user model for future usage. Learned REXML to parse the responses from the Foursquare API for user history, then created an import helper to turn Foursquare Venues into my internal Places model (while maintaining a strong reference to the foursquare id, to avoid duplicate creation).

Then I implemented the two major workhorse models used in Whirlfood — visits and ratings. Visits were pretty easy, they are simply many-to-many model with a timestamp to associate users with places and times (the equivalent of Foursquare’s checkin). Ratings were slightly more complex because they express the concept of “would you go back?” and are many-to-many between users and places, but don’t repeat every time the user visits. Would be pretty annoying if you got asked if you like Subway every time you went there for lunch… so when the rating occurs, you’re only asked to rate places that you visited but have never rated.

Additionally, the ratings controller was a little different because it needed to handle AJAX saves and responses so that a full page of new places can be rated without page reloads. Have to admit, the Rails way of doing this is pretty fantastic and foolproof…

Finally, I did some general controller workflow tweaking. For instance, when your new history is imported there are two possibilities: a) you have new places to rate or b) nothing new to rate. So depending on that case, the user will be redirected to the ratings controller or simply sent back home with a nice “nothing to do” notice. The flash[:notice] concept is another great idea that simplifies this very common function.

Also, in the import process, the import helper will only save new places if they fall into categories that the system knows about. This is because we want to filter out the noise of places like work, home and airports. To accomplish this, the Category model has aliases for each of our location providers (Foursquare, Gowalla, Facebook Places) that translate each of their proprietary category names into our common category system. And if a category is unrecognized, we simply don’t import that place.

So, the interface is pretty ugly right now, but the core integration functionality is completed. A new user can sign up, connect with Foursquare, import their checkin history, and rate their places. I even added a neat google map to the places show view.

Next up: need to build friends and version one of the actual recommendation system. And maybe spend a little time making the UI look nice. Then, I’ll need to spend some time working on the niceties like sending out a “Welcome to Whirlfood” email upon registration, for instance.

The Building-Learning Paradox

Christopher Gooley — Thu, 26 Aug 2010 20:08:12 +0000

If you want to learn a new langauge or framework you need a good project idea as the basis for what you’re building as you learn. But if you have a good project idea to work on, you want to get it to market as soon as possible. I present to you The Building-Learning Paradox.

I conjecture that this paradox is the reason that highly motivated people tend to learn in smaller incremental steps rather than diving head-first into a new technology. It’s basically impossible to satisfy both these main motivators at once. Not 100% sure what I’m going to do for this project I’m working on right now, but I think I’m going to sacrifice speed in order to learn something new. We’ll see if I can keep that up for very long.

How do you deal with this paradox? I’m curious.

Learning Rails – Day I

Christopher Gooley — Tue, 24 Aug 2010 01:30:22 +0000

I’ve been reading up a bit on Ruby and think I have a passable handle on the syntax. Also studied the structure of Rails apps. So now it’s time to actually build something to actually learn it. And because I have no patience for more Hello World examples, I’m going to build something actually useful.

Only problem is that I don’t have any tiny project ideas right now. So I’m going to re-work an existing idea and build a social restaurant recommendation site, based on my previous (poorly-named) Edahh project. If it turns out well, it might just be the basis for a re-launch of that service.

But let’s not get ahead of ourselves. First things first:
$ rails whirlfood -d mysql

And the adventure begins.