Why Before and after filters in Ruby on Rails? - Purpose & Use Cases

The Big Idea

What if you could write login checks and logs just once and have Rails do the rest automatically?

The Scenario

Imagine you have a web app where you must check user login before every page loads and log every action after it finishes.

You write this check and log code inside every controller action manually.

The Problem

Manually adding the same code everywhere is tiring and easy to forget.

If you miss one place, your app might let unauthorized users in or skip important logs.

It also makes your code messy and hard to update later.

The Solution

Before and after filters let you run code automatically before or after controller actions.

You write the check or log once, and Rails runs it for all relevant actions.

This keeps your code clean, consistent, and easy to maintain.

Before vs After

✗ Before

def show
  check_login
  # show action code
  log_action
end

✓ After

before_action :check_login
after_action :log_action

def show
  # show action code
end

What It Enables

You can easily add shared behavior across many actions without repeating code, making your app safer and cleaner.

Real Life Example

In a blog app, you want to verify the user is logged in before editing posts and log every edit after it happens.

Using filters, you add these checks once and they run automatically for all edit actions.

Key Takeaways

Manual repetition of checks and logs is error-prone and messy.

Before and after filters run code automatically around actions.

This keeps your app secure, clean, and easier to maintain.

Practice

1. What is the main purpose of a before_action filter in a Rails controller?

easy

A. To run code before a controller action executes

B. To run code after a controller action executes

C. To skip a controller action entirely

D. To define a new controller action

Solution

1. Step 1: Understand the role of filters

   Filters in Rails run code around controller actions to modify behavior.

2. Step 2: Identify the timing of before_action

   before_action runs code before the main action method executes.

3. Final Answer:

   To run code before a controller action executes -> Option A

4. Quick Check:

   before_action = runs before action [OK]

Hint: Before filters run code before actions start [OK]

Common Mistakes:

• Confusing before_action with after_action
• Thinking before_action skips actions
• Assuming before_action defines new actions

2. Which of the following is the correct syntax to define an after filter named log_action in a Rails controller?

easy

A. after_filter :log_action

B. after :log_action

C. before_action :log_action

D. after_action :log_action

Solution

1. Step 1: Recall the modern syntax for after filters

   Rails uses after_action to define code that runs after controller actions.

2. Step 2: Check each option

   after_filter :log_action uses deprecated after_filter. after_action :log_action uses correct after_action. before_action :log_action is for before filters. after :log_action is invalid syntax.

3. Final Answer:

   after_action :log_action -> Option D

4. Quick Check:

   Use after_action for after filters [OK]

Hint: Use after_action, not after_filter, for after filters [OK]

Common Mistakes:

• Using deprecated after_filter instead of after_action
• Mixing before_action with after filters
• Incorrect syntax like 'after :method'

3. Given this controller code:

class PostsController < ApplicationController
  before_action :set_post
  after_action :log_post

  def show
    render plain: @post.title
  end

  private
  def set_post
    @post = Post.find(params[:id])
  end

  def log_post
    Rails.logger.info "Post viewed: #{@post.id}"
  end
end

What will be the output when GET /posts/5 is called, assuming the post with ID 5 has title "Hello"?

medium

A. The page shows "Hello" and logs "Post viewed: 5" after rendering

B. The page shows "Hello" but does not log anything

C. The page shows nothing and logs "Post viewed: 5"

D. An error occurs because @post is not set

Solution

1. Step 1: Understand filter order and effects

   before_action :set_post runs before show, setting @post. after_action :log_post runs after show completes.

2. Step 2: Trace the request flow

   When show runs, @post is set, so render plain: @post.title outputs "Hello". After rendering, log_post logs "Post viewed: 5".

3. Final Answer:

   The page shows "Hello" and logs "Post viewed: 5" after rendering -> Option A

4. Quick Check:

   before_action sets data, after_action logs after render [OK]

Hint: before_action sets data, after_action runs after response [OK]

Common Mistakes:

• Thinking after_action runs before rendering
• Assuming @post is nil in show
• Confusing logging output with page content

4. Identify the error in this controller code:

class UsersController < ApplicationController
  before_action :authenticate_user
  after_action :clear_session

  def index
    # list users
  end

  private
  def authenticate_user
    redirect_to login_path unless current_user
  end

  def clear_session
    session[:temp] = nil
  end
end

medium

A. The methods authenticate_user and clear_session must be public

B. The before_action should be after_action for authentication

C. The after_action runs even if redirect happens, causing errors

D. There is no error; the code works as expected

Solution

1. Step 1: Analyze filter behavior with redirects

   If authenticate_user redirects, the action does not run, but after_action still runs.

2. Step 2: Understand consequences of after_action after redirect

   Running clear_session after redirect can cause unexpected side effects or errors.

3. Final Answer:

   The after_action runs even if redirect happens, causing errors -> Option C

4. Quick Check:

   after_action runs even after redirect [OK]

Hint: after_action runs even if before_action redirects [OK]

Common Mistakes:

• Assuming after_action skips on redirect
• Thinking authentication should be after_action
• Believing private methods must be public

5. You want to run a before_action filter named check_admin only before the edit and update actions in a Rails controller. Which is the correct way to write this?

hard

A. before_action :check_admin, except: [:edit, :update]

B. before_action :check_admin, only: [:edit, :update]

C. after_action :check_admin, only: [:edit, :update]

D. before_filter :check_admin, only: [:edit, :update]

Solution

1. Step 1: Identify correct filter type and options

   Use before_action to run code before actions. Use only: to limit to specific actions.

2. Step 2: Evaluate each option

   before_action :check_admin, only: [:edit, :update] correctly uses before_action with only: [:edit, :update]. before_action :check_admin, except: [:edit, :update] uses except, which excludes those actions. after_action :check_admin, only: [:edit, :update] uses after_action, wrong timing. before_filter :check_admin, only: [:edit, :update] uses deprecated before_filter.

3. Final Answer:

   before_action :check_admin, only: [:edit, :update] -> Option B

4. Quick Check:

   Use before_action with only: for specific actions [OK]

Hint: Use before_action with only: to target specific actions [OK]

Common Mistakes:

• Using except instead of only
• Using after_action instead of before_action
• Using deprecated before_filter