fix(desktop): extend CORS workaround to cover Access-Control-Allow-Headers#9753
fix(desktop): extend CORS workaround to cover Access-Control-Allow-Headers#9753ricardo777 wants to merge 1 commit intoente-io:mainfrom
Conversation
…-Headers for hosted S3 The allowAllCORSOrigins function already patches Access-Control-Allow-Origin when S3 providers return null. This PR does the same for Access-Control-Allow-Headers. Problem Some S3 providers have a hardcoded header whitelist in their server config that doesn't include all headers the desktop app sends (like x-client-version). When this happens, the browser blocks the request before it even goes out: Request header field x-client-version is not allowed by Access-Control-Allow-Headers in preflight response This broke uploads and downloads completely for me on a hosted setup using FileLu S5 as the S3 backend. The bucket CORS config was correct (<AllowedHeader>*</AllowedHeader>), but the provider's nginx was overriding it with a fixed list — so the bucket config had no effect. Fix When Access-Control-Allow-Headers comes back in a preflight response, override it with *. Same pattern as the existing ACAO fix.
|
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 213977bb6c
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| } else if (key.toLowerCase() == "access-control-allow-headers") { | ||
| headers["Access-Control-Allow-Headers"] = ["*"]; |
There was a problem hiding this comment.
allowAllCORSOrigins now rewrites every Access-Control-Allow-Headers header to *, but this same webContents session is also used for in-app Stripe checkout, and the adjacent comment already documents credentialed XHRs from that flow (desktop/src/main.ts:647-657). For credentialed preflights, browsers do not accept Access-Control-Allow-Headers: *, so a response that previously had a correct explicit allow-list can be turned into an invalid preflight response here, breaking payments again. This needs the same kind of conditional handling as the ACAO workaround instead of unconditionally replacing the server value.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
One follow-up question: FileLu returns a valid but incomplete list (e.g. missing x-client-version). The "null" check won't cover that case. Should we also override when the response ACAH doesn't include all requested headers from Access-Control-Request-Headers?
2 participants
Description
The allowAllCORSOrigins function already patches Access-Control-Allow-Origin when S3 providers return null. This PR does the same for Access-Control-Allow-Headers.
Problem
Some S3 providers have a hardcoded header whitelist in their server config that doesn't include all headers the desktop app sends (like x-client-version). When this happens, the browser blocks the request before it even goes out:
This broke uploads and downloads completely for me on a hosted setup using FileLu S5 as the S3 backend. The bucket CORS config was correct (*), but the provider's nginx was overriding it with a fixed list — so the bucket config had no effect.
Fix
When Access-Control-Allow-Headers comes back in a preflight response, override it with *. Same pattern as the existing ACAO fix.
Tests
Tested on Ente Desktop v1.7.21 against a self-hosted museum instance with FileLu S5 as the S3 backend.
Before: uploads and downloads failed with
x-client-version is not allowed by Access-Control-Allow-Headers in preflight responseAfter: error is gone, uploads and downloads work as expected.