Explain a Backend URL/page-origin mismatch instead of a bare fetch error

A real Windows install had sync and backups fail everywhere with
"Failed to fetch" while the server itself was fully healthy - confirmed
via Invoke-WebRequest returning 200 for every endpoint the browser
couldn't reach. The page was opened via a LAN IP while Settings still
had the Backend URL set to 127.0.0.1 from an earlier session; browsers
treat those as different origins, so the server's CORS check correctly
rejected the requests, but a CORS rejection surfaces to fetch() as an
unexplained generic error with no indication of the real cause.

Settings now detects this mismatch on every render and shows the page's
actual address with a one-click button to fix it.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
larssand
2026-09-09 12:06:58 +02:00
parent c53f31bf35
commit be9a2de31a
7 changed files with 52 additions and 3 deletions

View File

@@ -8,6 +8,12 @@ The application version is maintained in `package.json` and displayed in the adm
No changes recorded yet.
## 1.4.2 - 2026-09-09
### Fixed
- Sync and backups could fail everywhere with an unexplained "Failed to fetch", while the server itself was completely healthy, whenever the page was opened via a different address (e.g. a LAN IP) than the one saved in Settings under "Backend URL" - browsers treat those as different origins, and the browser's own security check (CORS) silently blocks the requests without explaining why. Settings now detects this mismatch, names the page's actual address, and offers a one-click button to fix it.
## 1.4.1 - 2026-09-09
### Fixed