umami-software
CORS headers not set when deploying to Fly.io
Describe the Bug
The expected header Access-Control-Allow-Origin is not set when deploying to Fly.io using the guides. As a result, we can‘t use it with Partytown, which requires the header to be set.
Access to fetch at 'https://analytics.<DOMAIN>/script.js' from origin 'http://localhost:4321' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
accept-ranges: bytes
cache-control: public, max-age=0
content-encoding: gzip
content-security-policy: default-src 'self';img-src * data:;script-src 'self' 'unsafe-eval' 'unsafe-inline';style-src 'self' 'unsafe-inline';connect-src 'self' api.umami.is cloud.umami.is;frame-ancestors 'self' undefined
content-type: application/javascript; charset=UTF-8
date: Fri, 13 Sep 2024 00:52:28 GMT
etag: W/"a11-19196e5b838"
fly-request-id: <REDACTED>
last-modified: Wed, 28 Aug 2024 02:52:03 GMT
server: Fly/0049c9a9 (2024-09-10)
vary: Accept-Encoding
via: 2 fly.io
x-dns-prefetch-control: on
Database
PostgreSQL
Relevant log output
No response
Which Umami version are you using? (if relevant)
v2.13.2
Which browser are you using? (if relevant)
Brave
How are you deploying your application? (if relevant)
Fly.io
@yeskunall, this is not related to Fly.io. The problem is, that the static asset/tracker script script.js is served by the Next.js server without an Access-Control-Allow-Origin header.
This itself is fine, as the header is not needed when a browser is instructed to load the script via a script tag. But, the header is required when the script is programmatically fetched via XmlHttpRequest or fetch.
As Partytown uses fetch inside the web worker to get the tracking script, the header Access-Control-Allow-Origin header is necessary in order to make Umami work with Partytown.
The header can easily be added for the tracker script. I tried it locally. Umami then correctly works with Partytown.
I will create a PR to suggest the change. 🙂
To sum it up and avoid any confusion: In my opinion, this issue is more about supporting Partytown in general.
@peter-kuhmann you’re absolutely correct. It has nothing to do with Fly.io. I updated the issue title and comment to reflect that.
Closing as this is now fixed.