Demande le manifeste PWA avec le cookie de session

Le navigateur demande `manifest.webmanifest` sans cookie par défaut : SSOwat ne reconnaît aucune session et redirige vers le portail YunoHost, qui est une autre origine — la réponse n'a pas d'Access-Control-Allow-Origin et le manifeste est bloqué. L'application fonctionnait quand même, ce qui rendait le défaut discret : ce qui tombait, c'est ce que le manifeste décide à l'INSTALLATION (nom, icônes, start_url, mode standalone). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-20 21:56:43 +02:00
parent 345422eda2
commit e74d20adfa
2 changed files with 38 additions and 1 deletions
@@ -2225,6 +2225,38 @@ Vérifié en exécution, styles calculés à l'appui : à 375 px, menu déployé
 1280 px, rangée horizontale centrée (six liens sur la même ligne à y = 55) et bascule
 `display: none`, sans débordement horizontal.

+### ⚠️ Le manifeste PWA se demandait sans cookie — bloqué par le portail
+
+Relevé dans la console de l'application installée, le 2026-08-20 :
+
+```
+Access to manifest at 'https://akbar.nohost.me/yunohost/sso?r=…'
+  (redirected from 'https://mabibli.akbar.nohost.me/manifest.webmanifest')
+  blocked by CORS policy: No 'Access-Control-Allow-Origin' header
+```
+
+**Le navigateur demande le manifeste sans cookie par défaut** — c'est une requête CORS
+anonyme, contrairement aux autres balises du `<head>`. SSOwat ne reconnaît donc aucune session
+et redirige vers le portail YunoHost, qui est **une autre origine** : la réponse ne porte aucun
+`Access-Control-Allow-Origin`, et le manifeste est purement et simplement jeté.
+
+D'où `crossorigin="use-credentials"` sur le `<link rel="manifest">`, qui fait porter le cookie
+de session à cette requête-là. C'est le remède standard de toute PWA derrière une
+authentification par portail, et il vaut pour **toutes** les instances YunoHost, pas seulement
+celle de l'utilisateur.
+
+⚠️ **Le symptôme n'est pas une application cassée, et c'est ce qui le rend facile à ignorer** :
+l'application fonctionne parfaitement dans le navigateur. Ce qui tombe, c'est ce que le
+manifeste décide **à l'installation** — nom, icônes, `start_url`, mode `standalone`. Une PWA
+installée depuis une page dont le manifeste n'a jamais été lu s'installe comme un simple
+raccourci de navigateur.
+
+⚠️ `index.html` est un fichier **statique**, pas du Razor : les commentaires y sont des
+`<!-- -->`. Un `@* … *@` y resterait du texte.
+
+Vérifié en exécution : `crossOrigin === "use-credentials"` sur le lien, manifeste servi en
+`200 application/manifest+json`, et plus aucune erreur le concernant dans la console.
+
 ### Un retour explicite dans le bandeau

 « Le déplacement est foireux » : d'un écran profond (bibliographie, fiche de tome, ajout
@@ -10,7 +10,12 @@
    <link rel="stylesheet" href="css/app.css" />
    <link rel="icon" type="image/png" href="favicon.png" />
    <link href="MaBibli.Client.styles.css" rel="stylesheet" />
-    <link href="manifest.webmanifest" rel="manifest" />
+    <!-- crossorigin="use-credentials" n'est PAS décoratif : sans lui, le navigateur demande le
+         manifeste SANS cookie, SSOwat ne reconnaît pas la session et redirige vers le portail
+         YunoHost — la réponse ne porte alors aucun Access-Control-Allow-Origin, et le manifeste
+         est purement et simplement bloqué. Voir CLAUDE.md, « Le manifeste PWA se demandait
+         sans cookie ». -->
+    <link href="manifest.webmanifest" rel="manifest" crossorigin="use-credentials" />
    <link rel="apple-touch-icon" sizes="512x512" href="icon-512.png" />
    <link rel="apple-touch-icon" sizes="192x192" href="icon-192.png" />
 </head>