Skip to main content

Troubleshooting

Handling CORS Restrictions for Chrome Extension Requests​

Problem​

Browsers enforce CORS policies to prevent unauthorized cross-origin requests. Requests made by Chrome extensions are blocked by default unless the server explicitly allows the extension's unique ID. Without proper configuration, these requests will fail due to CORS restrictions.

Solution​

Each Chrome extension has a unique ID generated from its manifest file. By configuring the backend API to allow this specific extension ID in CORS settings, we can bypass the restriction while maintaining security. The extension ID is stable, meaning it rarely changes, so adding it to the allowed origins solves the issue unless the extension is updated.

Server Configuration​

To enable CORS for the Chrome extension, the server’s ALLOWED_CORS environment variable was updated to include both the local development URL and the extension's unique ID:

ALLOWED_CORS="http://localhost:5173,chrome-extension://fhdpldnibaocgjobfdkikidckofodicc"

This allows requests from both the development environment and the Chrome extension, ensuring functionality while keeping security in check.

Updater Feed or TUF Metadata Shows the Old Version After Publish​

Problem​

Right after you publish or unpublish a version, a public URL still returns the previous content: a Velopack releases.{channel}.json, a Sparkle appcast.{channel}.xml, an edge response manifest, or TUF timestamp.json. The API and the database already show the new state.

Cause​

These files are regenerated on every publish, but they are served with Cache-Control: public, max-age=60, must-revalidate. Anything between the client and the bucket may serve its cached copy until that minute runs out. On Google Cloud Storage this happens even without a CDN: GCS serves public objects from Google's own cache.

Solution​

Wait up to 60 seconds; no action is needed. To confirm that faynoSync wrote the new file, request it with a unique query string, which bypasses the cache on GCS:

curl -s "https://storage.googleapis.com/your-public-bucket/velopack/admin/MyApp/windows/amd64/releases.stable.json?nocache=$(date +%s)"

If the fresh copy is correct, the delay is caching. If it is still old, check the server logs for the publish.