Skip to content

feat(water): moneaudebrassage.fr lookup in the web app - #70

Merged
ndreno merged 1 commit into
mainfrom
feat/mab-web
Nov 6, 2026
Merged

ndreno merged 1 commit into
mainfrom
feat/mab-web

Conversation

@ndreno

@ndreno ndreno commented Nov 6, 2026

Copy link
Copy Markdown
Contributor

Why

The web app said: "Live commune lookup is available in the desktop app only." The reason given in the code doesn't hold up today:

  • CORS: the API answers every origin with a matching Access-Control-Allow-Origin, including https://werb-dev.github.io, http://localhost:* and tauri://localhost.
  • Origin header: the API also answers without one. A GET with Accept: application/json is a simple request, so there is no preflight.
  • Live check: a browser fetch from https://werb-dev.github.io/werb/ in Chromium returned 200 with the data for 73008, 75056, 2A004, 13055 and 69123, and 404 for 00000.

The desktop's Origin: https://www.moneaudebrassage.fr header never reached the API anyway. Without the unsafe-headers feature, tauri-plugin-http drops forbidden headers and sends the webview origin.

Change

  • fetchCommuneAnalyses: browser fetch on the web, Tauri HTTP plugin on desktop, no Origin header.
  • MabLoader: the INSEE field and network list show everywhere. The desktop-only notice and the water.mab.web_unsupported error are removed.
  • The attribution line ("Water data © moneaudebrassage.fr") is unchanged.

The load on moneaudebrassage.fr stays small: one request per click on Load, and the last result is cached.

Tests

  • Unit: browser fetch outside Tauri, plugin under Tauri, exact URL and headers.
  • e2e: Settings, then My water lookup with a mocked API (page.route, service workers blocked so the route sees the request):
    • one network fills the ions;
    • several networks show a list, and picking one fills the ions.
  • Full e2e suite: 39 passed. Lint and typecheck are clean.
  • By hand: the local build against the live API lists both Aix-les-Bains networks.

The commune lookup was desktop only, on the assumption that the API
rejects cross-origin browser requests and requires an Origin header set
to www.moneaudebrassage.fr. Neither holds: the API answers any origin
with a matching Access-Control-Allow-Origin, and answers without an
Origin header too. A plain GET with Accept: application/json is a simple
request, so there is no preflight.

The desktop's Origin header never reached the API either: without the
unsafe-headers feature, tauri-plugin-http drops forbidden headers and
sends the webview origin (tauri://localhost).

- Web build uses the browser fetch; desktop keeps the Tauri HTTP plugin.
- No Origin header in the request.
- The desktop-only notice and the web_unsupported error are gone.

Tests: unit tests for the fetch choice and request shape; e2e looks up a
commune from Settings with a mocked API (one network fills My water,
several show a list to pick from). Checked by hand against the live API
from the deployed origin and from a local build.
@ndreno
ndreno merged commit 291396e into main Nov 6, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant