Issue with Cross-Origin Resource Sharing (CORS) Policy Mismatch in Squidex

I have…

  • Read the following guideline: Troubleshooting and Support | Squidex. I understand that my support request might get deleted if I do not follow the guideline.
  • Used code blocks with ``` to format my code examples like JSON or logs properly.

I’m submitting a…

  • Regression (a behavior that stopped working in a new release)
  • Bug report
  • Performance issue
  • Documentation issue or request

Current behavior

Error Type: Cross-Origin Resource Sharing (CORS) policy mismatch.

Description:
In our configuration, both our main application and Squidex are self-hosted in the Open Telekom Cloud. Additionally, we utilize Bunny CDN for content delivery. However, we’ve encountered issues with image loading from Squidex.

  • This issue occurs when our staging app and development app make requests to our development Squidex.
  • It appears that Squidex allows only one request at a time.
  • We attempted to allow access to all origins by adding environment variables and annotations in our ingress file.

Attempted Solutions:

  • Added the following environment variable:
env:
- name: CORS__ALLOWEDORIGINS
value: '*'
  • Added the following annotations in our ingress file:
ingress.kubernetes.io/enable-cors: "true"
ingress.kubernetes.io/cors-origins: "http://staging-app.com http://development-app.com"

Observations:

  • Setting CORS__ALLOWEDORIGINS to ‘*’ prioritizes the first specified origin and blocks subsequent origins.
  • For example, if we set http://development-app.com as the first allowed origin, http://staging-app.com will be blocked, and vice versa.
  • Purging the cache in Bunny CDN and making a request with one origin allows image loading for that origin but blocks the other.

Error Messages:

  • If development-app.com is allowed, the error message on staging-app.com will be:

Access to XMLHttpRequest at ‘https://development-squidex.our-app.dk/api/assets/cst/dbdb4daa-0322-4fsr-aeb8-171c5c00a763’ from origin ‘https://staging-app.com’ has been blocked by CORS policy: The ‘Access-Control-Allow-Origin’ header has a value ‘https://development-app.com’ that is not equal to the supplied origin.

  • If staging-app.com is allowed, the error message on development-app.com will be:

Access to XMLHttpRequest at ‘https://development-squidex.our-app.dk/api/assets/cst/dbdb4daa-0322-4fsr-aeb8-171c5c00a763’ from origin ‘https://development-app.com’ has been blocked by CORS policy: The ‘Access-Control-Allow-Origin’ header has a value ‘https://staging-app.com’ that is not equal to the supplied origin.

Expected behavior

Squidex should allow requests from multiple origins as configured.

Environment

  • Self hosted with docker
  • Self hosted with IIS
  • Self hosted with other version
  • Cloud version

Version: [VERSION]

Browser:

  • Chrome (desktop)
  • Chrome (Android)
  • Chrome (iOS)
  • Firefox
  • Safari (desktop)
  • Safari (iOS)
  • IE
  • Edge

Any guidance or support you can provide would be greatly appreciated.
Thank you for your attention to this matter.

Does not look like a Squidex problem for me. But when I google it, they use commas to separate origins.

Hi Sebastian,

Thanks for getting back to us. We tried separating the origins with a comma, but it didn’t change anything.

Also, we forgot to mention that the CORS error only happens for images on our Home page, not for images deeper in our app. Those load fine.

Initially, we suspected a caching problem and reached out to Bunny CDN for assistance. However, they suggested that the issue might be related to our CMS, which could be restricting the loading of resources from different main domains where the site is hosted. Consequently, they advised us to seek your guidance on resolving this matter.

Regarding this snippet from our Squidex configuration:

env:
- name: CORS__ALLOWEDORIGINS
value: '*'

Will this be enough for allowing multiple origins?

You cannot customize CORS settings in Squidex right now. It just allows all origins. Therefore I think it is not related.

Ok thanks for the reply. We’ll explore other alternatives to see if we can resolve this CORS issue. I might reach back to you if I need more guidance.