docs: log deferred sandbox-login CORS bug (Electron random port vs. real Stalwart origin)
This commit is contained in:
@@ -266,6 +266,19 @@ In rough order, per the `VNCprodbuild` skill:
|
||||
- **Expo Go + SQLCipher are mutually exclusive** — see §4/§6.1. The moment `useSQLCipher` is
|
||||
enabled, Expo Go can no longer run the app at all; this is a hard platform constraint, not a
|
||||
configuration bug to work around.
|
||||
- **Electron's random localhost port breaks JMAP login against the sandbox Stalwart —
|
||||
deferred, not fixed, 2026-08-04.** User confirmed testing the packaged Electron app directly
|
||||
against `stalwart.sandbox.vnc.de` (not `localhost`) hit a CORS-shaped login failure. Verified
|
||||
server-side: Stalwart's own CORS headers are correctly wildcarded (`Access-Control-Allow-Origin: *`)
|
||||
on every hop including the `.well-known/jmap` → `/jmap/session` redirect — so this is not a
|
||||
Stalwart allow-list problem. Also found, separately: `vncmail.sandbox.vnc.de` (the documented
|
||||
deployed webmail domain) currently does not resolve (NXDOMAIN) — unrelated to this bug but
|
||||
worth knowing regardless. Leading theory, not yet confirmed against real browser devtools:
|
||||
`electron/main.ts` binds the bundled Next.js server via `server.listen(0, ...)` — a random
|
||||
OS-assigned port every launch — producing a different origin on every run; even if that origin
|
||||
were allow-listed once, it wouldn't stay valid. **User explicitly said skip this for now** —
|
||||
Electron packaging/building itself works, this only affects live login against the sandbox.
|
||||
Fix path when revisited: bind Electron's local server to a fixed port instead of `0`.
|
||||
|
||||
## 9. Before merging any of this
|
||||
|
||||
|
||||
Reference in New Issue
Block a user