Bird
Raised Fist0
Ruby on Railsframework~15 mins

CORS configuration in Ruby on Rails - Mini Project: Build & Apply

Choose your learning style10 modes available
CORS configuration
📖 Scenario: You are building a Rails API that will be accessed by a frontend app running on a different domain. To allow the frontend to communicate with your API, you need to configure CORS (Cross-Origin Resource Sharing) properly.
🎯 Goal: Configure CORS in a Rails application to allow requests from the frontend domain http://localhost:3000.
📋 What You'll Learn
Create a new initializer file for CORS configuration
Set the allowed origin to http://localhost:3000
Allow HTTP methods GET, POST, and OPTIONS
Allow headers Content-Type and Authorization
💡 Why This Matters
🌍 Real World
Many web apps have frontend and backend on different domains or ports. CORS configuration allows the frontend to safely access backend APIs.
💼 Career
Backend developers often configure CORS to enable frontend apps to communicate with APIs securely and correctly.
Progress0 / 4 steps
1
Create the CORS initializer file
Create a new file called config/initializers/cors.rb and add the basic structure to configure CORS using the Rails.application.config.middleware.insert_before method.
Ruby on Rails
Hint

Use Rails.application.config.middleware.insert_before 0, Rack::Cors do ... end to start the CORS setup.

2
Add the allowed origin configuration
Inside the Rack::Cors block, add a allow block that sets the origins to 'http://localhost:3000'.
Ruby on Rails
Hint

Use allow do ... end and inside it set origins 'http://localhost:3000'.

3
Allow specific HTTP methods and headers
Inside the allow block, add resource configuration that allows all paths '*', permits HTTP methods GET, POST, and OPTIONS, and allows headers 'Content-Type' and 'Authorization'.
Ruby on Rails
Hint

Use resource '*', headers: [...], methods: [...] inside the allow block.

4
Complete and save the CORS configuration
Ensure the entire config/initializers/cors.rb file contains the full CORS configuration with insert_before, allow, origins, and resource settings as specified.
Ruby on Rails
Hint

Check that the file has the full configuration as in previous steps combined.

Practice

(1/5)
1. What is the main purpose of configuring CORS in a Rails application?
easy
A. To speed up database queries
B. To control which external websites can access your app's resources
C. To manage user sessions securely
D. To style the frontend pages

Solution

  1. Step 1: Understand CORS role

    CORS (Cross-Origin Resource Sharing) controls access from other websites to your app's resources.
  2. Step 2: Identify main purpose

    It restricts or allows external origins to make requests, enhancing security.
  3. Final Answer:

    To control which external websites can access your app's resources -> Option B
  4. Quick Check:

    CORS controls access = B [OK]
Hint: Remember CORS is about cross-site access control [OK]
Common Mistakes:
  • Confusing CORS with database or session management
  • Thinking CORS affects frontend styling
  • Assuming CORS speeds up app performance
2. Which of the following is the correct way to add CORS middleware in a Rails app initializer?
easy
A. Rails.application.config.middleware.insert_before 0, Rack::Cors do allow do origins '*' resource '*', headers: :any, methods: [:get, :post] end end
B. Rails.middleware.use Rack::Cors do allow do origins '*' resource '*', headers: :any, methods: [:get, :post] end end
C. config.middleware.add Rack::Cors do allow do origins '*' resource '*', headers: :any, methods: [:get, :post] end end
D. Rails.application.middleware.insert_after 0, Rack::Cors do allow do origins '*' resource '*', headers: :any, methods: [:get, :post] end end

Solution

  1. Step 1: Recall correct middleware insertion

    In Rails, middleware is added using Rails.application.config.middleware.insert_before or insert_after.
  2. Step 2: Identify correct syntax

    The common pattern is insert_before 0, Rack::Cors with a block for configuration.
  3. Final Answer:

    Rails.application.config.middleware.insert_before 0, Rack::Cors do allow do origins '*' resource '*', headers: :any, methods: [:get, :post] end end -> Option A
  4. Quick Check:

    Use insert_before 0 with config.middleware = C [OK]
Hint: Use Rails.application.config.middleware.insert_before 0 for CORS [OK]
Common Mistakes:
  • Using Rails.middleware instead of Rails.application.config.middleware
  • Using insert_after instead of insert_before 0
  • Missing config in middleware insertion
3. Given this CORS config in Rails initializer:
Rails.application.config.middleware.insert_before 0, Rack::Cors do
  allow do
    origins 'https://example.com'
    resource '*', headers: :any, methods: [:get, :post]
  end
end
What happens if a request comes from 'https://evil.com'?
medium
A. The request is blocked due to origin mismatch
B. The request causes a server error
C. The request is allowed but only GET method works
D. The request is allowed with all headers and methods

Solution

  1. Step 1: Analyze allowed origins

    The config allows only 'https://example.com' origin.
  2. Step 2: Check request origin

    Request from 'https://evil.com' is not in allowed origins, so it is blocked by CORS policy.
  3. Final Answer:

    The request is blocked due to origin mismatch -> Option A
  4. Quick Check:

    Origin not allowed = request blocked = D [OK]
Hint: Only origins listed in config are allowed [OK]
Common Mistakes:
  • Assuming wildcard '*' allows all origins when specific origins set
  • Thinking request causes server error instead of CORS block
  • Confusing allowed methods with allowed origins
4. You wrote this CORS config:
Rails.application.config.middleware.insert_before 0, Rack::Cors do
  allow do
    origins '*'
    resource '*', headers: :any, methods: [:get, :post, :put]
  end
end
But PUT requests from frontend are failing with CORS errors. What is the likely problem?
medium
A. The methods list is missing :put
B. The frontend is not sending the correct Origin header
C. The server needs to allow OPTIONS method for preflight
D. The origins '*' is too restrictive

Solution

  1. Step 1: Check methods allowed

    PUT is included in methods, so it's not missing.
  2. Step 2: Understand CORS preflight

    PUT requests trigger a preflight OPTIONS request which must be allowed by server.
  3. Step 3: Identify missing OPTIONS method

    OPTIONS method is not listed, so preflight fails causing CORS error.
  4. Final Answer:

    The server needs to allow OPTIONS method for preflight -> Option C
  5. Quick Check:

    Preflight OPTIONS missing = CORS fail = A [OK]
Hint: Always allow OPTIONS method for CORS preflight [OK]
Common Mistakes:
  • Forgetting to allow OPTIONS method
  • Assuming '*' origin is restrictive
  • Blaming frontend Origin header without checking server
5. You want to allow CORS only for two trusted domains: 'https://app1.com' and 'https://app2.com'. Which config correctly implements this securely in Rails?
hard
A. Rails.application.config.middleware.insert_before 0, Rack::Cors do allow do origins 'app1.com' resource '*', headers: :any, methods: [:get, :post, :options] end allow do origins 'app2.com' resource '*', headers: :any, methods: [:get, :post, :options] end end
B. Rails.application.config.middleware.insert_before 0, Rack::Cors do allow do origins '*' resource '*', headers: :any, methods: :any end end
C. Rails.application.config.middleware.insert_before 0, Rack::Cors do allow do origins 'app1.com', 'app2.com' resource '*', headers: :any, methods: [:get, :post] end end
D. Rails.application.config.middleware.insert_before 0, Rack::Cors do allow do origins 'https://app1.com', 'https://app2.com' resource '*', headers: :any, methods: [:get, :post, :options] end end

Solution

  1. Step 1: Identify correct origins format

    Origins must include full URLs with protocol for security, so 'https://app1.com' and 'https://app2.com' are correct.
  2. Step 2: Check methods and resource

    Allowing common methods including OPTIONS for preflight is necessary.
  3. Step 3: Compare options

    Rails.application.config.middleware.insert_before 0, Rack::Cors do allow do origins 'https://app1.com', 'https://app2.com' resource '*', headers: :any, methods: [:get, :post, :options] end end correctly lists both origins in one allow block with proper methods and full URLs.
  4. Final Answer:

    Rails.application.config.middleware.insert_before 0, Rack::Cors do allow do origins 'https://app1.com', 'https://app2.com' resource '*', headers: :any, methods: [:get, :post, :options] end end -> Option D
  5. Quick Check:

    Trusted full origins with methods including OPTIONS = A [OK]
Hint: List full trusted origins with needed methods including OPTIONS [OK]
Common Mistakes:
  • Using '*' origin which is insecure
  • Omitting protocol in origins
  • Not allowing OPTIONS method for preflight
  • Splitting origins into multiple allow blocks unnecessarily
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard