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:
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user