Question

I’ve put all of my user-authentication code in one place, namely lib/auth.rb. It looks like this:

lib/auth.rb

module Admin

  def do_i_have_permission_to?(permission)
    # Code to check all of this goes here
  end

end

I include this module as part of the application helper, so these functions are available in all the views:

application_helper.rb

require 'auth'
module ApplicationHelper
  include Admin
  # other stuff here
end

And I also include it as part of the application controller, so the controllers likewise can call the functions:

application.rb

require 'auth'
class ApplicationController < ActionController::Base
  include Admin
end

So far, so good.

The problem is that my application is not like a normal web app. Specifically, more than one user can be logged into the system from the same computer at the same time (using the same browser). I do authentication for actions by looking at all the people who are logged in from that IP and if they can all do it, it passes.

What this means is that, if an admin wants to do something, that admin has to log everyone else out first, which is annoying. But we want the admin seal of approval on everything the admin does. So the suggestion given to me was to have it so the admin can supply a username/password combo on any page they would not normally have access to (e.g. an ‘edit user’ page would have these extra input fields) and the authentication routines would check for that. This means

Admin::do_i_have_permission_to?(permission)

needs to get at the current request parameters. I can’t just use params[:foo] like I would in a controller, because params isn’t defined; similarly request.parameters[:foo] will also not work. My searching has revealed:

• The current search parameters are in the current request,
• The current request is in the current controller,
• The current controller is in the current dispatcher, and
• I’m not sure the current dispatcher is kept anywhere.

That said, experience tells me that when I’m jumping through this many hoops, I’m very probably Doing It Wrong. So what is the right way to do it? Options I’ve considered are:

• Just move all the functions currently in auth.rb into the ApplicationHelper where (I think) they’ll have access to the request and such. Works, but clutters the hell out of the helper.
• Move all the functions somewhere else they’ll see those methods (I don’t know where)
• I’m just plain missing something.

Answer 1

In a typical Rails application, authentication information is stored in the active session, not the parameters. As such, it’s pretty straightforward to write a helper that does what you want.

It seems rather unorthodox to create a module that is then included in ApplicationHelper. The traditional approach is to create a separate helper which in this case would probably be called AuthenticationHelper. This can then be included in any required controllers, or if you prefer, loaded into ApplicationController to make it available universally.

In general terms, Helpers should not include other Helpers. It is better to simply load multiple helpers into a given Controller.

Helper methods have full access to any instance variables declared within the controller context they are operating from. To be specific, these are instance variables only (@name) and not local variables (name). Helper methods are executed for a particular view as well.

Further, I’m not sure why a user would be providing credentials and performing an operation in the same step, at least for traditional web-based apps. Usually the process is to log in and then perform an action separately.

However, in the case of an API where each transaction is an independent operation, the most straightforward approach is to do is pull out the relevant request parameters that deal with authentication, establish some controller instance variables, and then proceed to perform the particular request given the constraints that the credentials impose.

The approach I usually follow for this sort of thing is to layer in an authentication structure in the ApplicationController itself which can perform the required checks. These are protected methods.

While it’s tempting to roll in a whole heap of them such as can_edit_user? and can_create_group? these very quickly get out of hand. It is a simpler design to put in a hook for a general-purpose can_perform? or has_authority_to? method that is passed an operation and any required parameters.

For example, a very rough implementation:

  class ApplicationController < ActionController::Base
  protected
    def has_authority_to?(operation, conditions = { })
      AuthenticationCheck.send(operation, conditions)
    rescue
      false
    end
  end

  module AuthenticationCheck
    def self.edit_user?(conditions)
      session_user == conditions[:user]
    end
  end

  class UserController
    # ...

    def edit
      @user = User.find(params[:id])

      unless (has_authority_to?(:edit_user, :user => @user))
        render(:partial => 'common/access_denied', :status => :forbidden)
      end
    rescue ActiveRecord::RecordNotFound
      render(:partial => 'users/not_found')
    end
  end

Obviously you’d want to roll a lot of the authority checks into before_filter blocks to avoid repetition and to promote consistency.

A full framework example might be of more help, such as the Wristband user authentication system:

http://github.com/theworkinggroup/wristband/tree/master