Issue to setup cors

Hi,

I’m trying to setup cors on kong but when it’s done I have only one header which is added but with this format: access-control-allow-origin.
Actually kong return me only these 2 headers:

access-control-allow-origin: *
access-control-expose-headers: Content-Length,Content-Range,Access-Control-Max-Age

The browser respond me something like that:

The resource at “<URL>” was blocked because content blocking is enabled.
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://mycdn.cloudfront.net/packs/js/runtime-e5736c99b302c5b67551.js. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing)

I’m running with kong in version 2.0.4 and ingress controller in vers 0.8.1

I don’t understand what I miss on the cors setup.

Following: crd config + kong config
yaml files:

apiVersion: configuration.konghq.com/v1
config:
  exposed_headers:
  - Content-Length
  - Content-Range
  - Access-Control-Max-Age
  headers:
  - Access-Control-Max-Age
  - Requested-With
  - If-Modified-Since
  - Cache-Control
  - Content-Type,Range
  max_age: 1728000
  methods:
  - GET
  - POST
  - OPTIONS
  origins:
  - '*'
  preflight_continue: true
kind: KongClusterPlugin
metadata:
  labels:
    global: "false"
  name: hivebrite-cors
plugin: cors
apiVersion: configuration.konghq.com/v1
kind: KongIngress
metadata:
  name: webapp
  namespace: default
route:
  strip_path: false
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    configuration.konghq.com: webapp
    konghq.com/plugins: hivebrite-cors
  name: webapp
  namespace: default
spec:
  rules:
  - host: '*.example.com'
    http:
      paths:
      - backend:
          serviceName: webapp
          servicePort: 9292
        path: /
  - host: example.com
    http:
      paths:
      - backend:
          serviceName: myapp
          servicePort: 9292
        path: /
  tls:
  - hosts:
    - '*.example.com'
    - example.com
    secretName: example-tls-cert

kong config:

enterprise:
  enabled: false
env:
  version: 2.0.4
  database: "off"
  headers: "off"
  stream_listen: "off"
  nginx_daemon: "off"
  nginx_worker_processes: 1
  admin_error_log: /dev/stderr
  admin_access_log: /dev/stdout
  admin_gui_error_log: /dev/stderr
  admin_gui_access_log: /dev/stdout
  proxy_error_log: /dev/stderr
  proxy_access_log: /dev/stdout
  portal_api_error_log: /dev/stderr
  portal_api_access_log: /dev/stdout
  nginx_http_include: /kong/servers.conf
  trusted_ips: 0.0.0.0/0,::/0
  real_ip_header: proxy_protocol
  real_ip_recursive: "on"
  proxy_listen: 0.0.0.0:8000 http2, 0.0.0.0:8443 http2 ssl
  admin_listen: 0.0.0.0:8444 http2 ssl
  status_listen: 0.0.0.0:8100
  prefix: /kong_prefix/
  lua_package_path: /opt/?.lua;/opt/?/init.lua;;
  plugins: bundled

@traines is the CORS expert I go to for help and he might have some insights here.

Where/how exactly are you seeing those headers from Kong? If access-control-allow-origin: * is indeed present, that request should be fine.

Can you provide a HAR of the complete page load?

Is this resource in fact proxied? CORS applies to all resources on the page, and https://mycdn.cloudfront.net/packs/js/runtime-e5736c99b302c5b67551.js may be something that it loads from somewhere elsewhere that’s not proxied by Kong–at least with the request and Ingress presented, it either isn’t or isn’t matched by that rule, as mycdn.cloudfront.net doesn’t match example.com. Those are presumably modified from their actual values, but there’s no way to tell if they match in the actual configuration.

mycdn.cloudfront.net is also presumably CloudFront rather than Kong itself, but it’s unclear if it’s CloudFront in front of Kong or CloudFront in front of S3 or similar that’s providing a resource loaded by something behind Kong.

Ok sorry for that, the kong was correctly setup.
In our setup cloudfront keep something in cache and we solve it to invalidate the cache

BTW, in our setup cloudfront is in front of our server which contains some assets