0

I have an ECS application with a React front end that's delivered via S3/CloudFront. For the back end, I have an application load balancer that routes traffic to my tasks (ruby on rails server).

In my Rails server config/application.rb I have

config.middleware.insert_before 0, Rack::Cors do
  allow do
    origins '*'
    resource(
      '*',
      headers: :any,
      expose: ["Authorization"],
      methods: [:get, :patch, :put, :delete, :post, :options, :show, :head]
    )
  end
end

When I create a service, I've been creating my ALB/Target Group/AutoScaler using the "create service" form. My ALB is listening on port 443 and I have a certification I created for the load balancer. If I set my Target group to have a protocol of HTTP (80) then my application starts up and works as expected.

Here's an example of a successful request: Note that the response headers all match my CORS configuration in my Application. Also note that the "Access-Control-Allow-Origin" is set to "*"

enter image description here

However, if I do the exact same thing with all the exact same settings - the only difference being that I change the protocol of the target group to HTTPS (443) then I get a CORS warning and an error stating ""access to fetch from origin" has been blocked"

enter image description here

I would think that '*' would cover both http and https since it basically whitelists everything, everywhere. And since I did not actually go in anywhere and modify any CORS settings anywhere, I would not think that changing the target group protocol would magically cause the "Access-Control-Allow-Origin" header to disappear

Any idea of how to resolve this? Based on this idiosyncrasy, it seems to me like it would be an issue with my AWS configuration as opposed to an application problem

APysnack
  • 73
  • 6

0 Answers0