question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

CORS response headers not applied when request origin not in explicit origins list

See original GitHub issue

Describe the bug

Note: this was reproduced using an external auth service configuration (configured as an API gateway plugin). It’s unclear at this time whether it affects the default authservice functionality that ships with AES

When one specifies an explicit list of origin values in the ambassador Module’s cors spec, and the preflight request’s Origin is not in this whitelist, the preflight request is sent to the auth service first, then forwarded to the API service where it will likely fail as the API service expects Ambassador to handle CORS concerns.

I don’t believe it’s intended that preflight requests should ever be routed to an API service, as the edge stack should handle that for us. When the request’s origin is found in the whitelist, the preflight request is only sent to the auth service (as expected).

To Reproduce

  1. Deploy an external auth service to your cluster alongside ambassador.
    1. Ensure it can respond appropriately to CORS preflight OPTIONS requests (credentials will not be present)
  2. Configure ambassador to disable the default auth service.
  3. Configure ambassador to use the AuthService plugin instead and point it at your external auth service.
  4. Provide a basic cors config with an explicit origins list in the ambassador Module
    cors:
        origins: "https://www.google.com"  # for example
        methods: GET, POST, PUT, PATCH, OPTIONS, DELETE
        headers: "*"
        exposed_headers: "*"
        max_age: "86400"
  1. Deploy a back end API service and an associated mapping
  2. Make a “non-simple” CORS request to your back end service
    1. Ensure that the request origin is not in the whitelist (i used chrome dev tools while on wikipedia’s home page)
    2. This is the simplest example to reproduce this behavior. You can achieve the same results even if you provide credentials on the request or modify the cors: spec to allow credentialed requests. See the attached document for a more complete listing.
fetch(
  'https://*******.com/edge/echo/ping',
  {
    mode: 'cors',
    method: 'POST',
    body: "{}",
    headers: {
      'Content-Type': 'application/json',
    }
  }
)
  1. Observe:
    1. the preflight request is successfully handled by the auth service (returns 200)
      1. it’s likely that having the auth service return a 4XX here if it determines origin is not allowed will prevent the preflight request from being forwarded to the API service. However, it still seems like a bug to send preflight requests to the API service regardless of the auth result.
    2. the preflight request is forwarded to the API service (this is the unexpected part)
    3. the API service returns a 401
      1. the 401 behavior is somewhat particular to our setup, but I’m including it here for completeness and noting that this may also play a part in the preflight response not having any CORS response headers

Expected behavior

  1. [Most important] Ambassador should not forward the preflight request to the API service under any circumstances.
  2. Ambassador should apply the remaining appropriate CORS response headers to the preflight request, even if the origin is not whitelisted, possibly informed by the auth service. In this case, it perhaps it should be that the Access-Control-Allow-Origin header is not present or is the empty string.
  3. Ambassador should respond with a 200 status code to the preflight OPTIONS request.
    1. There seems to be some wiggle room here in the CORS spec, so perhaps a 4XX is also acceptable. I believe browsers rely solely on the presence of the Access-Control-Allow-* headers to determine whether to deliver the response to the app or not and the status code is ignored.

Versions (please complete the following information):

  • Ambassador chart version: 6.5.9
  • Kubernetes environment: Self-managed on AWS
  • Ambassador version: 1.8.0

Additional context I don’t know if this is an Ambassador problem or an Envoy-proxy problem.

See the attached document for more details (and another type of CORS issue I have encountered) ambassador-cors-experiment.pdf

This seems possibly related to these issues: #2030 #2455

Issue Analytics

  • State:open
  • Created 3 years ago
  • Comments:5

github_iconTop GitHub Comments

1reaction
ayratncommented, Nov 20, 2020

We are experiencing the same issue in our product: we use external service to acknowledge API access and in case of 4xx errors client’s browser fails with CORS error in the console.

As a workaround we also keep CORS in two places now: CRD and auth-service code with CORS taken from application configuration.

We deploy to Openshift so at least we have single variable with the same CORS parameters which are injected both to CRD and auth-service, which seems at least minimizes the drawback of the workaround mentioned by @jcwilson.

Hoping to get it fixed soon anyway. Thank you.

0reactions
jcwilsoncommented, Feb 12, 2021

keeping this one alive for now

Read more comments on GitHub >

github_iconTop Results From Across the Web

Cross-Origin Resource Sharing (CORS) - MDN Web Docs
Cross-Origin Resource Sharing (CORS) is an HTTP-header based ... Note: Firefox has not implemented Range as a safelisted request-header yet.
Read more >
XMLHttpRequest cannot load XXX No 'Access-Control-Allow ...
If your client code does not explicit set affected Headers (e.g. "Accept") with a fix value in the request it might occur that...
Read more >
CORS support - IBM
However, when the origins do not match, a cross-origin request must be ... list of HTTP headers that are allowed to be used...
Read more >
Configuring CORS with Spring Boot and Spring Security
Cross-Origin Resource Sharing (CORS) is an HTTP-header-based mechanism that allows servers to explicitly allowlist certain origins and helps ...
Read more >
How to Debug Any CORS Error - HTTP Toolkit
Trying to request content from another origin that isn't explicitly available cross-origin. If its not your server, and it doesn't actively want CORS...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found