Two before_action calls, guarding every admin page at once

Free preview 2 min to read

Two before_action calls, inherited by every admin controller

This app's app/controllers/admin/base_controller.rb, in full:

module Admin
  class BaseController < ApplicationController
    before_action :require_login
    before_action :require_admin

    helper Admin::PaginationHelper
    layout "admin"
  end
end

Four lines of setup. Every Admin:: controller in this app, from Admin::Catalog::CoursesController to Admin::Identity::UsersController and Admin::Partners::PartnersController, inherits from Admin::BaseController and gets both before_action calls for free. Whoever writes Admin::Catalog::CoursesController#create never types "check that someone's logged in" or "check that they're an admin": both checks have run by the time their code does.

What before_action does

before_action :require_login registers a method, require_login, to run before every action in this controller and in every controller that inherits from it. require_login and require_admin are private methods on ApplicationController:

def require_login
  unless current_user
    flash[:alert] = t("common.flash.require_login")
    redirect_to auth_sign_in_path
  end
end

def require_admin
  unless admin?
    flash[:alert] = t("common.flash.require_admin")
    redirect_to root_path
  end
end

These are ordinary Ruby methods with nothing special in their bodies. What before_action adds is the guarantee that they run before whatever action a request asked for, without that action calling them.

The chain that runs before this one

Admin::BaseController isn't the first stop. It inherits from ApplicationController, which has three before_action calls of its own, set_current_user, set_locale and enforce_two_factor_setup, running on every request to every controller in the app, admin or not. So an admin request to, say, Admin::Catalog::CoursesController#index runs five of this app's before_action methods before index itself: three from ApplicationController and two from Admin::BaseController. The next lesson covers the order they run in, and why.

What this course covers

Seven lessons, all based on this app's controllers. This lesson covers the hook. Lesson 2 covers the order of that callback chain and how only: and except: narrow a callback to specific actions. Lesson 3 covers skip_before_action and the one place in this app where it removes CSRF checking on purpose. Lesson 4 covers rescue_from, this app's one use of it, and Rails' documentation on how it matches exceptions. Lesson 5 covers ActiveSupport::Concern, first with a disposable module, then inside Rails' before_action machinery, a generator template and this app's own concerns. Lesson 6 looks at a small duplication in this app that a concern could clean up and hasn't yet. Lesson 7 ends with a challenge that simulates the mechanism in plain Ruby.

Lesson 1 of 7 · free

Keep going with lesson 2

before_action mechanics: order, and narrowing with only:/except:

Parent callbacks run before child callbacks, only: and except: narrow actions, and performed? halts the chain.

A free account also gives you the quizzes, your progress and notes, and the discussion.

Type to start searching...