Before and after filters in Ruby on Rails - Step-by-Step Execution

Concept Flow - Before and after filters

Request received

↓

Run before filters

↓

Run controller action

↓

Run after filters

↓

Send response

Rails runs before filters first, then the action, then after filters before sending the response.

Execution Sample

Ruby on Rails

class PostsController < ApplicationController
  before_action :authenticate_user
  after_action :log_action

  def show
    # show post
  end
end

This code runs authenticate_user before show action, then runs log_action after it.

Execution Table

Step	Filter/Action	When Run	Effect	Notes
1	authenticate_user	Before action	Checks user login	Prevents action if not logged in
2	show	Action	Displays post	Main controller method
3	log_action	After action	Logs action details	Runs after action, before response sent
4	Response sent	After filters done	Sends page to user	End of request cycle

💡 Request ends after after_action filters run and response is sent

Variable Tracker

Variable	Start	After before_action	After action	After after_action	Final
user_authenticated	nil	true or false	true or false	true or false	true or false
response_ready	false	false	true	true	true
log_written	false	false	false	true	true

Key Moments - 3 Insights

Why does the before_action run before the controller method?

Because Rails runs all before_action filters first to prepare or check things before the main action runs, as shown in execution_table step 1 before step 2.

Can after_action filters change the response sent to the user?

Yes, after_action filters run after the action but before the response is sent, so they can modify the response (e.g., headers), mainly for logging or cleanup, as shown in execution_table step 3 before step 4.

What happens if a before_action filter stops the request?

If a before_action filter halts the request (like redirecting), the controller action and after_action filters do not run, stopping at that filter.

Visual Quiz - 3 Questions

Look at the execution_table, at which step does the main controller action run?

A Step 1

B Step 2

C Step 3

D Step 4

💡 Hint

Check the 'Filter/Action' column for the controller action name.

According to variable_tracker, when does 'log_written' become true?

A After after_action

B After action

C After before_action

D At start

💡 Hint

Look at the 'log_written' row and see when it changes to true.

If the before_action filter fails authentication, what happens next?

A Controller action runs anyway

B After_action runs but action does not

C Request stops before action and after_action

D Response is sent before filters

💡 Hint

Recall key_moments about before_action halting the request.

Concept Snapshot

Rails filters run in order:
- before_action: runs before controller method, used for checks
- controller action: main code for request
- after_action: runs after action, used for logging or cleanup
Filters help organize code around actions cleanly.

Full Transcript

In Rails, before_action filters run first to prepare or check things before the main controller action runs. Then the controller action executes to handle the request. After that, after_action filters run for tasks like logging. Finally, the response is sent to the user. If a before_action filter stops the request, the action and after_action filters do not run. Variables like user authentication status change during before_action, response readiness after the action, and logs are written after after_action. This flow helps keep controller code clean and organized.

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