GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS

Written by thoughtbot

Did You Order The Code Red?!

On Fridays, we enjoy getting together for lunch and reviewing code. This week, our liveliest discussion surrounded responsibility for authorization logic.

The problem ~ where does the authorization logic go?

You’ve come across it before: you have a User model and a second model for which users must be authorized to perform certain tasks:

def show
  @event = Event.find(params[:id])
  unless(
    logged_in? &&
    (
      @event.members.include?(current_user) ||
      @event.organizer.include?(current_user)
    ) ||
    current_user.admin?
  )
    flash[:failure] = "You are not authorized to view this event."
    redirect_to home_url and return
  end
end

In discussion, we decided there is too much logic in the controller. We want to move the authorization into the correct place in our domain model. But where?

unless current_user.authorized_for_event?(@event)</code>

That reads nicely in English as “Unless the current user is authorized for the event” but logically, a User should not be responsible for its own authorization.

Solution: non-User model authorizes User

The authorization logic should be on Event, not User.

Yawkey Way

For example, I have a ticket to a Red Sox game. When I arrive on Yawkey Way, the ticket-taker will authorize me to enter the event. He or she is the Controller in our MVC pattern. The ticket-taker doesn’t need to know that I paid with a MasterCard on September 20th or that my seat is in right field or any other details. All that matters is: is this guy authorized?

def attend
  @game = RedSoxGame.find_by_id params[:id]

  unless @game.authorized?(current_user)
    flash[:failure] = "You have no ticket for this game.
       Watch it over a pint of Sam Adams at the Cask n' Flagon."
    redirect_to home_url and return
  end
end

class RedSoxGame < ActiveRecord::Base
  def authorized?(user)
    return false if user.nil?
    doors_open? && not_rained_out? && user.ticket?(self) && user.not_drunk?
  end
end

The authorized method is noteworthy for two reasons. First, it uses the Composed Method:

Divide your program into methods that perform one identifiable task. Keep all of the operations in a method at the same level of abstraction. This will naturally result in programs with many small methods, each a few lines long.

The authorized? method is very easy to read because it focuses on simply authorizing the user for the game. It relies on a number of other methods whose purpose is clear and are similarly of narrow focus.

The second thing to note is that authorized? actually calls methods on the User model. It may seem contradictory to call User after saying that authorization logic does not belongs there. However, it isn’t authorization logic; it’s another level of abstraction.

Most importantly, the ticket-taker will let me into the Sox game.