Why authentication secures applications in Ruby on Rails - Challenge Your Understanding

Challenge - 5 Problems

❓ component_behavior

intermediate

What happens when a user tries to access a protected page without logging in?

Consider a Rails app with a before_action that requires authentication for certain pages. What will the user see if they try to visit a protected page without being logged in?

Ruby on Rails

class DashboardController < ApplicationController
  before_action :authenticate_user!

  def index
    render plain: "Welcome to your dashboard"
  end
end

A The user gets a 404 Not Found error.

B The user is redirected to the login page before seeing the dashboard.

C The user sees the dashboard content but with limited features.

D The user sees a blank page with no content.

💡 Hint

Think about what authenticate_user! does before the action runs.

The authenticate_user! method checks if the user is logged in. If not, it redirects them to the login page. This prevents unauthorized access to protected pages.

❓ state_output

intermediate

What is the value of current_user after a successful login?

In a Rails app using Devise, after a user logs in successfully, what does the helper method current_user return?

Ruby on Rails

user = User.create(email: "[e-mail]", password: "password")
# After logging in with these credentials
current_user

A An instance of the User model representing the logged-in user.

B nil, because current_user is only set during signup.

C A boolean true indicating the user is logged in.

D An error because current_user is undefined.

💡 Hint

current_user is a helper method provided by Devise.

After login, current_user returns the User object for the logged-in user. This lets the app know who is using it.

📝 Syntax

advanced

Which code snippet correctly restricts access to admin users only?

You want to allow only admin users to access the admin dashboard. Which before_action code correctly enforces this?

A

before_action :authenticate_user!, only: [:admin]
if !current_user.admin?
  redirect_to root_path
end

B

before_action :authenticate_user!, only: [:admin]
redirect_to root_path unless current_user.admin?

C

before_action :authenticate_user!, only: [:admin]
before_action :check_admin, only: [:admin]

def check_admin
  redirect_to root_path unless current_user.admin?
end

D

before_action :authenticate_user!, only: [:admin]
return redirect_to root_path unless current_user.admin?

💡 Hint

Think about where to put the admin check and how to use before_action properly.

Option C uses a separate method check_admin called by before_action. It redirects non-admin users safely before the action runs.

🔧 Debug

advanced

Why does this authentication code raise an error?

This code is meant to authenticate users but raises an error. What is the cause?

Ruby on Rails

class ApplicationController < ActionController::Base
  before_action :authenticate_user

  def authenticate_user
    unless current_user
      redirect_to login_path
      return
    end
  end
end

A before_action should call :authenticate_user! instead of :authenticate_user.

B The method name should be authenticate_user! with an exclamation mark.

C current_user is not defined in ApplicationController.

D redirect_to must be followed by return to stop execution.

💡 Hint

Think about what happens after redirect_to is called.

Without return, the action continues running after redirect_to, which can cause errors or unexpected behavior.

🧠 Conceptual

expert

Why is authentication critical for application security?

Which statement best explains why authentication is essential to secure a web application?

A It verifies the identity of users to prevent unauthorized access to sensitive data and actions.

B It encrypts all data sent between the user and server to protect privacy.

C It automatically fixes security bugs in the application code.

D It speeds up the application by caching user sessions.

💡 Hint

Think about what authentication does before allowing access.

Authentication confirms who the user is. This stops strangers from accessing private parts of the app, protecting data and functionality.

Practice

1. Why is authentication important in a Rails application?

easy

A. It automatically fixes bugs in the code.

B. It speeds up the application loading time.

C. It verifies the identity of users before granting access.

D. It changes the application's design theme.

Solution

1. Step 1: Understand the purpose of authentication

   Authentication is the process of checking who a user is before allowing access to certain parts of an application.

2. Step 2: Identify the correct role of authentication in Rails

   In Rails, authentication protects private data and user accounts by verifying user identity.

3. Final Answer:

   It verifies the identity of users before granting access. -> Option C

4. Quick Check:

   Authentication = Verify identity [OK]

Hint: Authentication means checking who you are before access [OK]

Common Mistakes:

• Confusing authentication with performance optimization
• Thinking authentication changes app design
• Believing authentication fixes code bugs automatically

2. Which of the following is the correct way to add Devise authentication to a Rails model named User?

easy

A. Add before_action :authenticate_user! in the User model.

B. Add authenticate :user in the routes file.

C. Add has_secure_password in the User controller.

D. Add devise :database_authenticatable, :registerable inside the User model.

Solution

1. Step 1: Identify how Devise is used in models

   Devise requires adding devise with modules inside the model class to enable authentication features.

2. Step 2: Check each option's correctness

   Add devise :database_authenticatable, :registerable inside the User model correctly shows adding devise :database_authenticatable, :registerable inside the User model. Other options misuse syntax or place code in wrong files.

3. Final Answer:

   Add devise :database_authenticatable, :registerable inside the User model. -> Option D

4. Quick Check:

   Devise modules go inside model class [OK]

Hint: Devise modules go inside model class, not routes or controller [OK]

Common Mistakes:

• Placing authentication code in routes or controllers incorrectly
• Using has_secure_password instead of Devise syntax
• Calling authenticate_user! in model instead of controller

3. Given this Rails controller code using Devise:

class DashboardController < ApplicationController
  before_action :authenticate_user!

  def index
    render plain: "Welcome, #{current_user.email}!"
  end
end

What will happen if an unauthenticated user tries to access /dashboard?

medium

A. They will be redirected to the sign-in page.

B. They will see the welcome message with their email.

C. They will get a 404 Not Found error.

D. They will see a blank page.

Solution

1. Step 1: Understand before_action :authenticate_user! behavior

   This method checks if a user is signed in; if not, it redirects to the sign-in page.

2. Step 2: Predict the controller response for unauthenticated user

   Since the user is not signed in, the controller will redirect them to the login page instead of showing the welcome message.

3. Final Answer:

   They will be redirected to the sign-in page. -> Option A

4. Quick Check:

   Unauthenticated user = redirect to sign-in [OK]

Hint: authenticate_user! redirects unauthenticated users to login [OK]

Common Mistakes:

• Assuming unauthenticated users see content
• Thinking it returns 404 error
• Expecting a blank page instead of redirect

4. You added before_action :authenticate_user! in your Rails controller, but unauthenticated users can still access protected pages. What is the most likely cause?

medium

A. You did not add devise_for :users in routes.rb.

B. You placed before_action after the action methods.

C. You did not restart the Rails server after adding authentication.

D. You forgot to include Devise in your Gemfile.

Solution

1. Step 1: Check the role of devise_for :users in routes

   This line sets up all necessary routes for Devise authentication, including sign-in and sign-out paths.

2. Step 2: Understand impact of missing routes

   If devise_for :users is missing, authentication paths do not exist, so authenticate_user! cannot redirect unauthenticated users properly.

3. Final Answer:

   You did not add devise_for :users in routes.rb. -> Option A

4. Quick Check:

   Missing devise routes = no authentication redirects [OK]

Hint: Devise needs routes set with devise_for :users [OK]

Common Mistakes:

• Assuming server restart fixes missing routes
• Placing before_action incorrectly does not bypass it
• Forgetting to add Devise gem causes errors, not silent failure

5. You want to secure an API endpoint in Rails so only authenticated users can access it. You use Devise and add before_action :authenticate_user! in your API controller. However, API clients get redirected to the sign-in page instead of receiving an error. How can you fix this to return a 401 Unauthorized status instead?

hard

A. Add skip_before_action :authenticate_user! in the API controller.

B. Override Devise's authenticate_user! to respond with JSON and 401 status for API requests.

C. Remove before_action :authenticate_user! and check authentication manually.

D. Change the API controller to inherit from ApplicationController instead of ActionController::API.

Solution

1. Step 1: Understand default Devise behavior for unauthenticated users

   Devise redirects unauthenticated users to sign-in page by default, which is not suitable for APIs.

2. Step 2: Customize authentication failure response for API

   Override the failure response to return JSON with 401 Unauthorized status when API requests fail authentication.

3. Final Answer:

   Override Devise's authenticate_user! to respond with JSON and 401 status for API requests. -> Option B

4. Quick Check:

   API auth failure = JSON 401, not redirect [OK]

Hint: API needs JSON 401 response, not redirect [OK]

Common Mistakes:

• Removing authentication check loses security
• Skipping before_action disables protection
• Changing controller inheritance does not fix response format