feat(mobile): proxie le téléchargement de l'APK via l'API (pas de CORS) #77

Merged

kyuno merged 1 commit from feat/mobile-download-proxy into main

2026-09-06 23:58:21 +02:00

kyuno commented

2026-09-06 23:40:42 +02:00

Owner

Suite au fix de /releases/latest (précédent), l'utilisateur voulait un lien qui déclenche le téléchargement du .apk directement, sans quitter l'appli web.

Vérifié en direct : fetch("https://git.dev.kyuno.fr/api/...") depuis le navigateur échoue avec Failed to fetch (confirmé via un essai en mode no-cors : la requête réseau aboutit bien, seule la réponse est bloquée) — Forgejo n'envoie aucun header CORS sur son API Releases, publique ou non.

Ça ne concerne pas que la page d'accueil : le hook de vérification de mise à jour (#66, useAppUpdateCheck) faisait exactement le même fetch cross-origin depuis la WebView native, et échouait donc tout aussi silencieusement en production sans que personne ne puisse s'en rendre compte (le hook avale toute erreur réseau par design).

Fix : petit module apps/api/src/modules/mobile/ (2 routes publiques, aucune ne touche la base de données) :

GET /mobile/latest-release → { version } (proxy JSON, remplace le fetch direct de useAppUpdateCheck)
GET /mobile/download → redirection 302 vers l'asset .apk réel de la dernière release (ou vers la page /releases/latest en repli si Forgejo est injoignable ou qu'aucun .apk n'est encore attaché)

Côté frontend : LandingPage.tsx et UpdateBanner.tsx pointent maintenant vers ce proxy (${API_BASE_URL}/mobile/download, target="_blank") au lieu d'une URL Forgejo directe — un clic, téléchargement immédiat, jamais de navigation hors de l'appli.

Vérifié en local (sans Postgres, ces routes n'en ont pas besoin) contre les vraies données Forgejo :

GET /mobile/latest-release -> {"version":"v0.2.0"}
GET /mobile/download -> 302, Location vers le vrai .apk signé

pnpm lint / tsc (api + web) / pnpm --filter web build : tous verts. Le scénario Cypress "offers the Android app download" échoue encore en local (même souci pré-existant déjà documenté sur la PR précédente, confirmé indépendant du code par la vraie CI) — mis à jour pour asserter le nouveau href relatif.

🤖 Generated with Claude Code

Suite au fix de `/releases/latest` (précédent), l'utilisateur voulait un lien qui déclenche le téléchargement du `.apk` directement, sans quitter l'appli web. **Vérifié en direct** : `fetch("https://git.dev.kyuno.fr/api/...")` depuis le navigateur échoue avec `Failed to fetch` (confirmé via un essai en mode `no-cors` : la requête réseau aboutit bien, seule la réponse est bloquée) — Forgejo n'envoie aucun header CORS sur son API Releases, publique ou non. **Ça ne concerne pas que la page d'accueil** : le hook de vérification de mise à jour (#66, `useAppUpdateCheck`) faisait exactement le même fetch cross-origin depuis la WebView native, et échouait donc tout aussi silencieusement en production sans que personne ne puisse s'en rendre compte (le hook avale toute erreur réseau par design). **Fix** : petit module `apps/api/src/modules/mobile/` (2 routes publiques, aucune ne touche la base de données) : - `GET /mobile/latest-release` → `{ version }` (proxy JSON, remplace le fetch direct de `useAppUpdateCheck`) - `GET /mobile/download` → redirection 302 vers l'asset `.apk` réel de la dernière release (ou vers la page `/releases/latest` en repli si Forgejo est injoignable ou qu'aucun `.apk` n'est encore attaché) Côté frontend : `LandingPage.tsx` et `UpdateBanner.tsx` pointent maintenant vers ce proxy (`${API_BASE_URL}/mobile/download`, `target="_blank"`) au lieu d'une URL Forgejo directe — un clic, téléchargement immédiat, jamais de navigation hors de l'appli. **Vérifié en local** (sans Postgres, ces routes n'en ont pas besoin) contre les vraies données Forgejo : ``` GET /mobile/latest-release -> {"version":"v0.2.0"} GET /mobile/download -> 302, Location vers le vrai .apk signé ``` `pnpm lint` / `tsc` (api + web) / `pnpm --filter web build` : tous verts. Le scénario Cypress "offers the Android app download" échoue encore en local (même souci pré-existant déjà documenté sur la PR précédente, confirmé indépendant du code par la vraie CI) — mis à jour pour asserter le nouveau `href` relatif. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

kyuno added 1 commit 2026-09-06 23:40:42 +02:00

feat(mobile): proxie le telechargement de l'APK via l'API (pas de CORS)

CI / lint (push) Successful in 2m59s

Details

CI / build (push) Successful in 3m4s

Details

CI / intent-service-test (push) Successful in 4m46s

Details

CI / e2e (push) Successful in 9m33s

Details

CI / test (push) Successful in 17m20s

Details

CI / build-android (push) Has been skipped

Details

3abb7217dd

Suite au fix de /releases/latest (precedent), l'utilisateur voulait un
lien qui declenche le telechargement du .apk directement, sans quitter
l'appli web. Verifie en direct : fetch("https://git.dev.kyuno.fr/api/...")
depuis le navigateur echoue avec "Failed to fetch" (confirme via un essai
en mode no-cors : la requete reseau aboutit bien, seule la reponse est
bloquee) — Forgejo n'envoie aucun header CORS sur son API Releases,
publique ou non. Ca ne concerne pas que la page d'accueil : le hook de
verification de mise a jour (#66, useAppUpdateCheck) faisait exactement le
meme fetch cross-origin depuis la WebView native, et echouait donc tout
aussi silencieusement en production sans que personne ne puisse s'en
rendre compte (le hook avale toute erreur reseau par design).

Ajoute un petit module apps/api/src/modules/mobile/ (2 routes publiques,
aucune ne touche la base de donnees) :
- GET /mobile/latest-release -> { version } (proxy JSON, remplace le fetch
  direct de useAppUpdateCheck)
- GET /mobile/download -> redirection 302 vers l'asset .apk reel de la
  derniere release (ou vers la page /releases/latest en repli si
  Forgejo est injoignable ou qu'aucun .apk n'est encore attache)

Cote frontend : LandingPage.tsx et UpdateBanner.tsx pointent maintenant
vers ce proxy (`${API_BASE_URL}/mobile/download`, target="_blank") au lieu
d'une URL Forgejo directe — un clic, telechargement immediat, jamais de
navigation hors de l'appli. useAppUpdateCheck.ts appelle desormais
apiClient.getLatestMobileVersion() au lieu d'un fetch direct.

Verifie en local (sans Postgres, ces routes n'en ont pas besoin) contre
les vraies donnees Forgejo :
  GET /mobile/latest-release -> {"version":"v0.2.0"}
  GET /mobile/download -> 302, Location vers le vrai .apk signe

pnpm lint / tsc (api + web) / pnpm --filter web build : tous verts. Le
scenario Cypress "offers the Android app download" echoue encore en local
(meme souci pre-existant deja documente sur la PR precedente, confirme
independant du code par CI reel) ; mis a jour pour asserter le nouveau
href relatif.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>