Rails before_action vs before_filter: What's the Difference in Rails 4?

By the end of this page, you will understand how controller callbacks work in Rails, why before_action and before_filter look identical in Rails 4, and which one you should use in modern Rails applications. You will also see practical examples, common patterns, and mistakes to avoid when using callbacks in controllers.

In Rails controllers, a callback lets you run code automatically before, after, or around controller actions such as index, show, create, or update.

For example, you might want to:

• load a record before show
• check authentication before edit
• verify authorization before destroy
• set common data for multiple actions

Historically, Rails used names like:

• before_filter
• after_filter
• around_filter

Later, Rails introduced clearer names:

• before_action
• after_action
• around_action

In Rails 4, before_action was added as a clearer, preferred name for before_filter. For a time, they both worked and were effectively aliases of each other. In other words, they referred to the same callback mechanism.

Think of a controller action like entering a room to perform a task.

• The action is the task you came to do.
• A before_action is the checklist you complete before entering.
• An after_action is the cleanup you do afterward.
• An around_action is someone watching the whole process from start to finish.

before_filter and before_action are like two labels for the same checklist in Rails 4. Rails eventually preferred the label that makes more sense: action.

The basic syntax for a controller callback in Rails looks like this:

class PostsController < ApplicationController
  before_action :set_post, only: [:show, :edit, :update, :destroy]

  def show
  end

  private

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

What this does

Before Rails runs the show, edit, update, or destroy action, it first calls set_post.

That means @post is already available inside those actions and their views.

Older equivalent syntax

class PostsController < ApplicationController
  before_filter ,  [, , , ]

   
  

  

   
     = .find(params[])
  

Consider this controller:

class PostsController < ApplicationController
  before_action :set_post, only: [:show]

  def show
    @title = @post.title.upcase
  end

  private

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

Now imagine a request comes in for:

GET /posts/5

Step-by-step

1. Rails receives the request for show.

2. Rails checks whether any callbacks should run before show.

3. before_action :set_post, only: [:show] matches, so Rails runs set_post.

4. Inside set_post, Rails runs:

Controller callbacks are very common in real Rails apps.

1. Authentication

before_action :authenticate_user!

Used to make sure a user is signed in before accessing protected pages.

2. Loading shared records

before_action :set_order, only: [:show, :update, :cancel]

Avoids repeating @order = Order.find(params[:id]) in multiple actions.

3. Authorization

before_action :require_admin, only: [:destroy]

Prevents non-admin users from accessing sensitive actions.

4. Setting common view data

before_action :load_categories

Useful when many actions need the same sidebar or navigation data.

5. Request preparation

before_action :normalize_search_params, only: [:index]

In real projects, developers usually use callbacks for shared controller concerns, but they try to keep callbacks focused and easy to understand.

Common patterns

Guard clauses for access control

before_action :require_login

private

def require_login
  return if current_user
  redirect_to login_path, alert: "Please sign in"
end

This is simple and readable: allow the request if the condition is met; otherwise redirect early.

Shared setup methods

before_action :set_project, only: [:show, :edit, :update]

private

def set_project
  @project = Project.find(params[:id])
end

This avoids duplication across multiple actions.

Using callbacks with strong parameters indirectly

Callbacks often prepare state, while the action handles saving:

def update
   .update(project_params)
    redirect_to 
  
    render 
  

1. Thinking before_filter and before_action are different features in Rails 4

In Rails 4, they are effectively aliases for the same controller callback behavior.

2. Using old naming in new code

Broken from a style perspective, even if it may still work in some versions:

before_filter :set_post

Preferred modern style:

before_action :set_post

Use the current convention so your code matches Rails guides and generators.

3. Forgetting to limit the callback to relevant actions

Problematic:

before_action :set_post

If index or new does not have params[:id], this may fail.

Better:

before_action :set_post, only: [:show, :edit, :update, :destroy]

4. Putting too much logic inside a callback

before_filter vs before_action

# Modern Rails callback
before_action :method_name

# Older alias seen in older code
before_filter :method_name

# Limit callback to certain actions
before_action :set_post, only: [:show, :edit, :update, :destroy]

# Exclude certain actions
before_action :authenticate_user!, except: [:index, :show]

Key facts

• before_action runs before a controller action.
• In Rails 4, before_action and before_filter are effectively aliases.
• Use before_action in modern code.
• Common uses:
  • authentication
  • authorization
  • loading records
  • setting shared data
• Keep callbacks small and focused.
• Prefer clear method names like set_post, require_login, load_categories.
• Use only: or except: to avoid running callbacks where they do not belong.

Is before_filter deprecated in Rails 4?

Rails 4 introduced before_action as the preferred name. In later Rails versions, before_filter was deprecated and then removed, so modern code should use before_action.

Do before_action and before_filter behave differently?

In Rails 4, for normal controller usage, they are effectively the same callback mechanism.

Why did Rails rename before_filter to before_action?

Because before_action is clearer and better describes that the callback runs before a controller action.

Should I replace before_filter in older projects?

If you are maintaining an older app, updating to before_action can improve consistency and help with future Rails upgrades.

When should I use before_action?

Use it for shared controller setup such as loading records, checking authentication, or enforcing authorization.

Can I overuse controller callbacks?

Yes. Too many callbacks can make controller flow hard to follow. Keep them small, clear, and limited to shared concerns.

• Controller callbacks — The broader feature that includes before_action, after_action, and around_action.
• ApplicationController — Common place to define shared controller behavior across many controllers.
• Authentication — A very common use case for before_action.
• Authorization — Another common callback use case for controlling access.
• Strong parameters — Frequently used alongside callbacks in CRUD controllers.
• RESTful routes — Helps explain why callbacks often target actions like show, edit, update, and destroy.
• Guard clauses — Useful style for writing clear callback methods.
• DRY (Don’t Repeat Yourself) — Callbacks are often used to remove repeated setup code.