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>