ruby 45 lines · 9 steps

How before_action filters guard a Rails controller

A Rails controller layers authentication, record loading, and ownership checks through ordered before_action filters.

Explained by highlit
1class ArticlesController < ApplicationController
2 before_action :authenticate_user!
3 before_action :set_article, only: %i[show edit update destroy]
4 before_action :authorize_owner!, only: %i[edit update destroy]
5 skip_before_action :authenticate_user!, only: %i[index show]
6 
7 def index
8 @articles = Article.published
9 end
10 
11 def show
12 end
13 
14 def edit
15 end
16 
17 def update
18 if @article.update(article_params)
19 redirect_to @article, notice: "Article updated."
20 else
21 render :edit, status: :unprocessable_entity
22 end
23 end
24 
25 def destroy
26 @article.destroy
27 redirect_to articles_path, notice: "Article deleted."
28 end
29 
30 private
31 
32 def set_article
33 @article = Article.find(params[:id])
34 end
35 
36 def authorize_owner!
37 return if @article.user == current_user
38 
39 redirect_to articles_path, alert: "Not authorized."
40 end
41 
42 def article_params
43 params.require(:article).permit(:title, :body, :published)
44 end
45end
01 / 01
STEP 01

Walkthrough

Space play step click any line
Three takeaways
  1. 1before_action filters run in declaration order, so authentication, loading, and authorization stack predictably around each action.
  2. 2Scoping filters with only:/skip lets one controller serve public reads and protected writes without per-action conditionals.
  3. 3Returning early from an authorization filter and redirecting halts the action chain before the body ever runs.

Related explainers

Share this explainer

Here's the card — post it anywhere.

How before_action filters guard a Rails controller — share card
Made with highlit — turn any snippet into a walkthrough like this in about a minute.
Explain your code