Duas chamadas before_action, protegendo toda página admin de uma vez

Duas chamadas before_action, herdadas por todo controller do admin

O app/controllers/admin/base_controller.rb deste app, por inteiro:

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

    helper Admin::PaginationHelper
    layout "admin"
  end
end

Quatro linhas de configuração. Todo controller Admin:: deste app, do Admin::Catalog::CoursesController ao Admin::Identity::UsersController e ao Admin::Partners::PartnersController, herda de Admin::BaseController e ganha as duas chamadas before_action de graça. Quem escreve Admin::Catalog::CoursesController#create nunca digita "confira se alguém está logado" nem "confira se é admin": as duas conferências já rodaram quando o código dele roda.

O que o before_action faz

before_action :require_login registra um método, require_login, para rodar antes de toda ação deste controller e de todo controller que herda dele. require_login e require_admin são métodos privados do 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

São métodos Ruby comuns, sem nada especial no corpo. O que o before_action acrescenta é a garantia de que eles rodam antes da ação que a requisição pediu, sem que essa ação os chame.

A cadeia que roda antes desta

O Admin::BaseController não é a primeira parada. Ele herda do ApplicationController, que tem três chamadas before_action próprias, set_current_user, set_locale e enforce_two_factor_setup, rodando em toda requisição a todo controller do app, admin ou não. Então uma requisição de admin para, digamos, Admin::Catalog::CoursesController#index roda cinco métodos before_action deste app antes do próprio index: três do ApplicationController e dois do Admin::BaseController. A próxima aula trata da ordem em que eles rodam, e do porquê.

O que este curso cobre

Sete aulas, todas sobre os controllers deste app. Esta aula trata do gancho. A aula 2 trata da ordem dessa cadeia de callbacks e de como only: e except: restringem um callback a certas ações. A aula 3 trata do skip_before_action e do único lugar deste app em que ele tira a checagem de CSRF de propósito. A aula 4 trata do rescue_from, do único uso dele neste app e da documentação do Rails sobre como ele casa exceções. A aula 5 trata do ActiveSupport::Concern, primeiro com um módulo descartável, depois dentro da maquinaria de before_action do Rails, num template de gerador e nos concerns do próprio app. A aula 6 olha uma pequena duplicação deste app que um concern poderia limpar e ainda não limpou. A aula 7 fecha com um desafio que simula o mecanismo em Ruby puro.