Chrome blocking due to CORS policy violation about data-upstream-service-201902 HOT 8 CLOSED

The error message explains it all. We have two options here -- make sure the server returns the specific origin that it accepts (in this case, http://localhost:4200) or ensure that the credentials mode is not include.

The previous version has already handled the first case. At the same time, using the second case is easy, too, by setting withCredentials to false here.

@afitterling please advice how do you want to proceed with this.

from data-upstream-service-201902.

Yihang, cors is already being setup in config/initializers/cors.rb
So I applied the patch to the frontend, as it was the frontend. What implication does it have?

from data-upstream-service-201902.

No, the setup isn't the same as the old code. In the new code, the origin is hard-coded to '*', which causes the problem. In the old code, a specific origin is provided based on the value of ENV["PERMITTED_ORIGIN"].

from data-upstream-service-201902.

yes, of course I know. the wildcard for dev environment however should work. also setting the host specifc does not work.

from data-upstream-service-201902.

@yihang, the app fix does not work either, it keeps redirecting. Is there an easy fix with the current rails setup (using wildcard)?

from data-upstream-service-201902.

In addition to setting the host, we also need to set credentials: true. The full fix looks like this:

# config/initializers/cors.rb

Rails.application.config.middleware.insert_before 0, Rack::Cors do
  allow do
    origins 'http://localhost:4200'

    resource '*',
      headers: :any,
      methods: [:get, :post, :options],
      credentials: true
  end
end

Obviously, we don't want to hard code the value of the origin here. I still stand by what I recommended (and did) in the past, which is to inject this value by an environment variable. I don't think this is a big deal as this value is not something that changes frequently in practice (e.g., when doing development, it's almost always localhost:4200).

To explain why wildcard used to work and why credentials: true was not needed previous, the rack-cors library has changed its behavior between the time we installed in the old code base and now. Previously, rack-cors automatically replaces the '*' origin with the actual origin that it sees. It doesn't do this anymore, that is, if we specify '*', it will set that as the Access-Control-Allow-Origin header with it verbatim. Also, the value of credentials used to default to true but now defaults to false.

On a related note, I think issues like this should have been caught during the upgrade process. I am not sure how you did it, but any major upgrade (like this) should have been done piecewise in baby steps. Each step should be followed by rigorous testing to isolate any issues to a single cause.

from data-upstream-service-201902.

Yihang. you were right, wildcard works not anymore. we set it statically and use env in production. The profile cannot be loaded currently, this is due the to included session module. very good.

from data-upstream-service-201902.

fixed

from data-upstream-service-201902.