CORS response headers missing from OPTIONS request in rack app

[johnknapp]

I've verified my cors setup and read through other issues in this repo. Not sure what else to investigate and welcome your advice.

My environment:

• https://api.herokuapp.com
  • ruby 2.7.1
  • roda 3.36 (framework)
  • rack-cors 1.1.1
  • origins https://app.herokuapp.com
  • resource '*', headers: :any, methods: %i[get post put delete options head]
• https://app.herokuapp.com
  • svelte 3.29.7
  • fetch api
  • credentials: 'include'
  • mode: 'cors'
  • method: 'POST'

Problem statement:

• A POST request gets 200 OK from OPTIONS and cors headers are missing!
• Consequently, the POST is blocked with the standard error
  • Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Etcetera:

• Following this helpful SO post I did a test with curl (using -X OPTIONS with a non localhost origin header) and observed the same absence of cors response headers to my preflight.
• There is only one other rack middleware (Rack::Session::Cookie) in the mix.
• I've confirmed the other roda headers are working as expected.

[cyu]

@johnknapp bear with me, I've never worked with Roda before.

Can you show me how you're setting up that middleware along side the Roda app?

[johnknapp]

Yes Calvin, I'll provide more detail. I've been in touch with roda author on this and he agrees it is an odd one. My aim is an example to reproduce the problem. -JK

[johnknapp]

Alright @cyu here is a public repo with a minimal rack-cors / roda test app which replicates the problem reported. The readme in that repo explains the testing methodology.

I hope you can help resolve this issue!

With a cc to @jeremyevans, the author of roda.

[jeremyevans]

Looking at the test Roda application, the pizza stuff is ignored (hash_branch is called with a symbol, not a string). Additionally, the json plugin doesn't seem to be used, so even if the pizza branch was taken, it would probably result in an exception being raised.

Does it reproduce with the following config.ru? (this is the rough equivalent of what the example Roda app does, just with fewer headers)

require 'rack/cors'

  use Rack::Cors do
    allowed_methods = %i[get post put delete options head]
    allow do
      origins 'https://rack-cors-roda.herokuapp.com/'
      resource '*', headers: :any, methods: allowed_methods
    end
  end

s = 'hello rack-cors'
run(proc do |env|
  if env['PATH_INFO'] == '/'
    [200, {'Content-Length'=>s.length}, [s.dup]]
  else
    [404, {'Content-Length'=>0}, ['']]
  end
end)

[johnknapp]

Thank you @jeremyevans for this pure rack test.

A preflight curl test as documented in the readme still exhibits this problem! (Pure rack with puma, roda gem has been removed.)

You can see what I tested on heroku in this branch of my rack-cors test repo. Note the change in Gemfile, Gemfile.lock, config.ru, and README.md.

Let's see what @cyu has to say about this pure rack test.

[johnknapp]

UPDATE:

1. I did a heroku test of the pure rack example. This curl preflight response had cors headers.
2. Noticing the example used webrick vs puma and rack-cors1.1.0 vs 1.1.1, I made added puma and rolled rack-cors back to 1.1.0 in my config.ru test from @jeremyevans. This curl preflight response did not have cors headers.

• I believe this eliminates any regression in rack-cors 1.1.1.
• I believe this highlights a problem in the rack-cors configuration in the config.ru specimen listed above and failing on heroku curl test.
• Grasping at straws, I observed the rack-cors example rack app uses a Rack::Builder.app block wrapped round the app. I added that block to our failing config.ru to no avail.

Perhaps @cyu can point out the misconfiguration in our config.ru as seen in our repository which, running on heroku and testing with curl, returns no response headers to a cors preflight test as documented in the readme of that branch of that repo.

[johnknapp]

I added debug: true and logged results on heroku:

Dec 18 13:41:04 rack-cors-roda heroku/router at=info method=OPTIONS path="/" host=rack-cors-roda.herokuapp.com request_id=699b502a-2707-4ac9-80be-a051ed456495 fwd="<ip addy snipped>" dyno=web.1 connect=1ms service=16ms status=200 bytes=71 protocol=https
Dec 18 13:41:04 rack-cors-roda app/web.1 D, [2020-12-18T21:41:04.430276 #4] DEBUG -- : Incoming Headers:
Dec 18 13:41:04 rack-cors-roda app/web.1   Origin: https://random-sample.herokuapp.com
Dec 18 13:41:04 rack-cors-roda app/web.1   Path-Info: /
Dec 18 13:41:04 rack-cors-roda app/web.1   Access-Control-Request-Method: POST
Dec 18 13:41:04 rack-cors-roda app/web.1   Access-Control-Request-Headers: X-Requested-With
Dec 18 13:41:04 rack-cors-roda app/web.1 D, [2020-12-18T21:41:04.430440 #4] DEBUG -- : Preflight Headers:

To be clear, there were no further log entries after this!

[johnknapp]

I switched to a wildcard cors origin and got preflight response headers:

Dec 18 13:50:41 rack-cors-roda heroku/router at=info method=OPTIONS path="/" host=rack-cors-roda.herokuapp.com request_id=ba854b6e-1bbe-42a2-afc4-27b0dcc88157 fwd="73.223.174.252" dyno=web.1 connect=0ms service=7ms status=200 bytes=280 protocol=https
Dec 18 13:50:41 rack-cors-roda app/web.1 D, [2020-12-18T21:50:40.900613 #4] DEBUG -- : Incoming Headers:
Dec 18 13:50:41 rack-cors-roda app/web.1   Origin: https://random-sample.herokuapp.com
Dec 18 13:50:41 rack-cors-roda app/web.1   Path-Info: /
Dec 18 13:50:41 rack-cors-roda app/web.1   Access-Control-Request-Method: POST
Dec 18 13:50:41 rack-cors-roda app/web.1   Access-Control-Request-Headers: X-Requested-With
Dec 18 13:50:41 rack-cors-roda app/web.1 D, [2020-12-18T21:50:40.900801 #4] DEBUG -- : Preflight Headers:
Dec 18 13:50:41 rack-cors-roda app/web.1   Access-Control-Allow-Origin: *
Dec 18 13:50:41 rack-cors-roda app/web.1   Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS, HEAD
Dec 18 13:50:41 rack-cors-roda app/web.1   Access-Control-Expose-Headers: 
Dec 18 13:50:41 rack-cors-roda app/web.1   Access-Control-Max-Age: 0
Dec 18 13:50:41 rack-cors-roda app/web.1   Access-Control-Allow-Headers: X-Requested-With

Inspired, I went back to my production roda app and set a wildcard origin. A POST request from my javascript front end (svelte app using fetch) received expected response headers from the preflight request. Which unsurprisingly failed thus:

Response to preflight request doesn't pass access control check: The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'.

Then I removed `credentials: 'include, mode: 'cors' from my JS fetch POST and achieved a successful cross platform POST to my back end. Naturally, my back-end sent cookies back to the browser.

But of course with a wildcard cors origin, the browser will not accept cookies. That is a show stopper for us.

Summary of the current situation:

• Using rack-cors, I must use a wildcard origin to get preflight response headers.
• Using a wildcard cors origin, the browser will not accept cookies.

The solution we need is simple:

• Using rack-cors, we must set a proper cors origin on our back end so our front-end will eat our cookies.

[cyu]

@johnknapp try removing the trailing '/' from the origin.

[johnknapp]

To @cyu:

• I already tried that.
• I also tried a (well tested) regex origin (without trailing slash.)

What else?

[cyu]

@johnknapp I just tested and that works. I think your test is invalid. Using your example test:

• Remove the trailing slash from the origins statement when configuring Rack::Cors
• Make sure the Origin: header you're passing when using curl is missing a trailing slash
• Make sure the Origin you're passing is consistent (in the curl example your origin https://random-sample.herokuapp.com, but the expected origin is https://rack-cors-roda.herokuapp.com/)

[johnknapp]

@cyu Thank you Calvin! I would like to leave this open for the moment until I do a bit more testing tomorrow. I confirmed my config.ru works without slash but the typical roda approach of configuring rack middlewares within the app subclass of Roda is failing still. It will probably turn out rack-cors needs to install within config.ru instead of the common roda approach.

To help other roda users, I'll confirm this and comment here before closing.

[cyu]

@johnknapp when I tested I did test with both the use command in config.ru and also inside the Roda subclass, and in both cases it worked.

[johnknapp]

Confirmed, thank you again @cyu. I updated my rack-cors + roda repository to reflect reality and added notes which may help others in the future. (With a cc to @jeremyevans, thanks to you too!)