cors mapping doesnt work with filters

Describe the bug When filter is specified then CORS specified for mapping doesn’t work. As I understand maybe filters are applied before mapping, but I didn’t found any way for filter to be aplied after mapping or to pass OPTIONS request.

To Reproduce I have mapping and OIDC filter specified together for a service

apiVersion: getambassador.io/v2
kind: FilterPolicy
metadata:
  name: api-filter-policy
spec:
  rules:
    - host: api.example.com
      path: "*"
      filters:
        - name: api-filter

apiVersion: getambassador.io/v2
kind: Filter
metadata:
  name: api-filter
spec:
  OAuth2:
    authorizationURL: "https://keycloak.example.com/auth/realms/api"
    grantType: "AuthorizationCode"
    protectedOrigins:
      - origin: "https://api.example.com"
        internalOrigin: "*://*"
    audience: api-client
    clientID: api-client
    secret: "secretString"

apiVersion: getambassador.io/v2
kind: Mapping
metadata:
  name: api-mapping
spec:
  host: api.example.com
  prefix: /
  service: api-service:8080
  cors:
    origins: '*'
    methods: '*'
    headers: '*'

Expected behavior A way for CORS to work with filters

Versions (please complete the following information):

• Ambassador: 1.7.0
• Kubernetes environment bare metal
• Version v1.18.8

[paulwitt]

We’re having the same issue. When the Filter and FilterPolicy aren’t in place the CORS mapping works just as expected. @havenotfear 's comment is an issue for us as our JWT Filter is the only token validation we have in place. If there was a way to link mappings to filterpolicies then we might be able to work around this using the method definition of the mapping. But as far as I can tell, the only thing linking filters/filterpolicies to mappings is the host definition.

(EDIT) We’re still testing it but I think this will work around the issue:

kind: FilterPolicy
metadata:
  name: my-service
  namespace: my-service
spec:
  rules:
  - host: my-service.my-domain.com
    path: "*"
    filters:
    - name: my-service
      namespace: my-service
      ifRequestHeader:
        name: ":method"
        value: "OPTIONS"
        negate: true
      arguments:
        ...```

[michael4screen]

Hi @havenotfear ,

I came accross because i have the same issue right now. Your solution might work but you will allow any request to bypass your auth filter only by setting the Access-Control-Request-Method header. If i understand it correctly, your solution is not restricted to allow OPTIONS requests only. This is a security issue then.

Maybe you have found another solution already ?