Rate limiting in Ruby on Rails - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What happens when a user exceeds the rate limit in Rails with Rack::Attack?

Consider a Rails app using Rack::Attack to limit requests to 5 per minute per IP. What is the typical response when a user exceeds this limit?

Ruby on Rails

class Rack::Attack
  throttle('req/ip', limit: 5, period: 1.minute) do |req|
    req.ip
  end
end

A The server responds with HTTP status 500 Internal Server Error.

B The server queues the request and processes it later.

C The server responds with HTTP status 429 Too Many Requests.

D The server ignores the limit and processes the request normally.

💡 Hint

Think about the standard HTTP status code for too many requests.

Rack::Attack returns HTTP 429 status code when the request limit is exceeded, signaling the client to slow down.

📝 Syntax

intermediate

Identify the correct syntax to throttle requests by user ID in Rack::Attack

Which of the following code snippets correctly throttles requests to 10 per minute per user ID in a Rails app using Rack::Attack?

A throttle('req/user', limit: 10, period: 1.minute) { |req| req.session[:user_id] }

B throttle('req/user', limit: 10, period: 1.minute) { |req| req.user_id }

C throttle('req/user', limit: 10, period: 1.minute) { |req| req.user.id }

D throttle('req/user', limit: 10, period: 1.minute) { |req| req.params[:user_id] }

💡 Hint

Remember that Rack::Attack works on the Rack request object, which has params but not user methods.

Rack::Attack's block receives a Rack::Request object, which has access to params. Using req.params[:user_id] correctly extracts the user ID for throttling.

🔧 Debug

advanced

Why does this Rack::Attack throttle not work as expected?

Given this code snippet, users are not being throttled correctly. What is the most likely cause? class Rack::Attack throttle('logins/ip', limit: 5, period: 20.seconds) do |req| if req.path == '/login' && req.post? req.ip end end end

Ruby on Rails

class Rack::Attack
  throttle('logins/ip', limit: 5, period: 20.seconds) do |req|
    if req.path == '/login' && req.post?
      req.ip
    end
  end
end

A The condition returns nil for non-login requests, causing Rack::Attack to count them incorrectly.

B The throttle block should always return a string, but req.ip returns an integer.

C The throttle period is too short to trigger throttling.

D The throttle name 'logins/ip' is invalid and causes the throttle to be ignored.

💡 Hint

Think about what happens when the block returns nil for some requests.

If the block returns nil, Rack::Attack ignores that request for throttling. Returning nil for non-login requests is expected and does not cause counting issues. However, if the condition is incorrect or the path check is wrong, it might cause unexpected behavior.

🧠 Conceptual

advanced

What is the main benefit of using Redis with Rack::Attack for rate limiting?

Why do many Rails apps use Redis as the cache store for Rack::Attack when implementing rate limiting?

A Redis automatically blocks IPs without any configuration.

B Redis provides fast, centralized storage to track request counts across multiple app servers.

C Redis encrypts all request data for security.

D Redis replaces the need for Rack::Attack middleware.

💡 Hint

Think about how multiple servers share state for rate limiting.

Redis is a fast in-memory store that allows multiple app instances to share request count data, enabling consistent rate limiting across servers.

❓ state_output

expert

What is the value of the counter after 3 requests from the same IP in 1 minute with this Rack::Attack throttle?

Given this throttle configuration, what is the value stored in the cache for the key 'rack::attack:throttle:logins/ip:1.2.3.4' after 3 POST requests to '/login' from IP '1.2.3.4' within 1 minute? class Rack::Attack throttle('logins/ip', limit: 5, period: 60.seconds) do |req| req.ip if req.path == '/login' && req.post? end end

Ruby on Rails

class Rack::Attack
  throttle('logins/ip', limit: 5, period: 60.seconds) do |req|
    req.ip if req.path == '/login' && req.post?
  end
end

A 3

B 5

C 0

D nil

💡 Hint

Each matching request increments the counter by 1.

Each POST request to '/login' from the same IP increments the counter by 1. After 3 such requests, the counter value is 3.

Practice

1. What is the main purpose of rate limiting in a Rails application?

easy

A. To control how often users can make requests to the server

B. To speed up database queries automatically

C. To style the user interface dynamically

D. To manage user sessions securely

Solution

1. Step 1: Understand rate limiting concept

   Rate limiting is about controlling the number of requests a user can make in a time period.

2. Step 2: Identify the main purpose in Rails context

   It helps protect the server from overload and abuse by limiting request frequency.

3. Final Answer:

   To control how often users can make requests to the server -> Option A

4. Quick Check:

   Rate limiting = controlling request frequency [OK]

Hint: Rate limiting controls request frequency to protect servers [OK]

Common Mistakes:

• Confusing rate limiting with UI styling
• Thinking it speeds up database queries
• Mixing it with session management

2. Which of the following is the correct way to configure a simple rate limit using Rack::Attack in Rails?

easy

A. Rack::Attack.throttle('req/ip', limit: 5, period: 1.minute) { |req| req.ip }

B. Rack::Attack.limit('req/ip', 5, 1.minute) { |req| req.ip }

C. Rack::Attack.throttle('req/ip', 1.minute, limit: 5) { |req| req.ip }

D. Rack::Attack.block('req/ip', limit: 5, period: 1.minute) { |req| req.ip }

Solution

1. Step 1: Recall Rack::Attack throttle syntax

   The correct method is throttle with arguments: name, limit, period, and a block returning the key.

2. Step 2: Match syntax with options

   Rack::Attack.throttle('req/ip', limit: 5, period: 1.minute) { |req| req.ip } uses throttle with named parameters limit: 5 and period: 1.minute, and block returning req.ip, which is correct.

3. Final Answer:

   Rack::Attack.throttle('req/ip', limit: 5, period: 1.minute) { |req| req.ip } -> Option A

4. Quick Check:

   Correct method and parameters = Rack::Attack.throttle('req/ip', limit: 5, period: 1.minute) { |req| req.ip } [OK]

Hint: Use throttle with named limit and period parameters [OK]

Common Mistakes:

• Using wrong method name like limit or block
• Swapping limit and period order
• Not passing a block returning the key

3. Given this Rack::Attack throttle configuration:

Rack::Attack.throttle('logins/ip', limit: 3, period: 20.seconds) { |req| req.ip if req.path == '/login' && req.post? }

What happens if a user makes 4 POST requests to '/login' within 20 seconds from the same IP?

medium

A. Only the 1st request is blocked

B. The 4th request is blocked due to rate limit

C. All 4 requests are allowed without restriction

D. The 4th request resets the limit counter

Solution

1. Step 1: Understand throttle parameters

   The limit is 3 requests per 20 seconds per IP for POST requests to '/login'.

2. Step 2: Analyze 4 POST requests from same IP

   The first 3 requests pass, the 4th exceeds the limit and is blocked.

3. Final Answer:

   The 4th request is blocked due to rate limit -> Option B

4. Quick Check:

   Requests > limit = block excess [OK]

Hint: Requests over limit within period get blocked [OK]

Common Mistakes:

• Assuming all requests pass
• Thinking limit resets on 4th request
• Confusing which requests count

4. You wrote this code to limit API requests:

Rack::Attack.throttle('api/ip', limit: 10, period: 1.minute) do |req|
  req.ip if req.path.start_with?('/api')
end

But users report no limits are applied. What is the likely problem?

medium

A. The period should be in seconds, not minutes

B. The limit value 10 is too high to trigger blocking

C. The block returns nil for non-API paths, so no key is generated for those requests

D. The method throttle is not supported in Rack::Attack

Solution

1. Step 1: Check block return value logic

   The block returns req.ip only if path starts with '/api', else returns nil.

2. Step 2: Understand throttle key generation

   If block returns nil, no key is generated and no limit applies for those requests.

3. Final Answer:

   The block returns nil for non-API paths, so no key is generated for those requests -> Option C

4. Quick Check:

   Nil key means no rate limiting applied [OK]

Hint: Block must return key for all requests to apply limits [OK]

Common Mistakes:

• Thinking limit 10 is too high
• Confusing period units
• Believing throttle method is unsupported

5. You want to limit login attempts per user email and IP address separately using Rack::Attack. Which configuration correctly applies this?

hard

A. Rack::Attack.throttle('logins/email', limit: 5, period: 1.hour) { |req| req.params['email'].presence }Rack::Attack.throttle('logins/ip', limit: 10, period: 1.hour) { |req| req.params['email'] }

B. Rack::Attack.throttle('logins/email_ip', limit: 5, period: 1.hour) { |req| req.params['email'] + req.ip }

C. Rack::Attack.throttle('logins/email', limit: 5, period: 1.hour) { |req| req.ip }Rack::Attack.throttle('logins/ip', limit: 10, period: 1.hour) { |req| req.params['email'] }

D. Rack::Attack.throttle('logins/email', limit: 5, period: 1.hour) { |req| req.params['email'] }Rack::Attack.throttle('logins/ip', limit: 10, period: 1.hour) { |req| req.ip }

Solution

1. Step 1: Understand separate throttles for email and IP

   We want one throttle keyed by email, another keyed by IP address.

2. Step 2: Match keys to correct throttle names

   Rack::Attack.throttle('logins/email', limit: 5, period: 1.hour) { |req| req.params['email'] }
   Rack::Attack.throttle('logins/ip', limit: 10, period: 1.hour) { |req| req.ip } correctly uses req.params['email'] for email throttle and req.ip for IP throttle with proper limits.

3. Final Answer:

   Rack::Attack.throttle('logins/email', limit: 5, period: 1.hour) { |req| req.params['email'] }
   Rack::Attack.throttle('logins/ip', limit: 10, period: 1.hour) { |req| req.ip } -> Option D

4. Quick Check:

   Separate keys for email and IP = Rack::Attack.throttle('logins/email', limit: 5, period: 1.hour) { |req| req.params['email'] }
   Rack::Attack.throttle('logins/ip', limit: 10, period: 1.hour) { |req| req.ip } [OK]

Hint: Use separate throttle blocks keyed by email and IP [OK]

Common Mistakes:

• Mixing email and IP keys in wrong throttles
• Concatenating email and IP as one key
• Using IP where email key is needed