f9fe0e3419
**Motivations:** - Partie connectée du skeleton accessible seulement si pairing satisfait + relais OK, avec page type skeleton (avatar, notifications). - Éviter « Aucun service disponible » : contrat présent en dur dans la page, transmis à l’iframe ; navigation évidente ou automatique vers login. - Sécuriser postMessage (origine UserWallet uniquement) ; déployer data sur le proxy et certificat data.certificator.4nkweb.com. - Vulgariser cryptographie (ECDH, AES-GCM, Schnorr, workflow, collecte signatures) ; documenter correctifs et architecture. **Root causes:** - Section connectée affichée sans vérifier pairing/relay ; possibilité de forger pairing-relay-status depuis la console. - Iframe masquée ou /login chargé avant réception du contrat → graphe vide, redirection vers /services. - Pas de contrôle d’origine sur les messages reçus ; pas de projet website-data ni config Nginx/certificat pour data. **Correctifs:** - Vérification msg.origin === USERWALLET_ORIGIN dans handleMessage (skeleton). - Si session mais pas pairingRelayStatus : afficher iframe pour réception du statut, message « Vérification du statut… ». - Contrat envoyé dès load iframe (init iframe.src = USERWALLET_ORIGIN) ; au clic « Se connecter », envoi contract + navigate-login (service, membre). - UserWallet : écoute navigate-login → navigation /login?service=&membre= ; LoginScreen avec service+membre en URL ne redirige plus vers /services, dispatch E_SELECT_SERVICE / E_SELECT_MEMBER. **Evolutions:** - Message pairing-relay-status (iframe → parent) ; canShowConnectedSection exige login + pairing OK + relay OK ; page connectée avec header avatar + icône notifications. - Skeleton : getLoginContext, sendNavigateLoginToIframe, onIframeLoad, loginRequested/iframeLoaded ; contrat envoyé avec serviceUuid, membreUuid. - UserWallet : PairingRelayStatusMessage, envoi depuis HomeScreen/LoginScreen ; type navigate-login, handleNavigateLogin dans useChannel. - Page cryptographie.html (workflow, algorithmes, collecte signatures) ; liens nav, build. - website-data (Vite, channel, config), start/service/install ; configure-nginx-proxy + Certbot pour data.certificator.4nkweb.com. - fixKnowledge (postmessage-origin, section-connectee-non-affichee) ; features (partie-connectee-pairing-relay, userwallet-iframe-key-isolation). **Pages affectées:** - website-skeleton (index, main, config, serviceContract, cryptographie, technique, membre, contrat, vite.config, README). - userwallet (HomeScreen, LoginScreen, useChannel, iframeChannel, relay, crypto, iframe, Pairing*, RelaySettings, WordInputGrid, syncUpdateGraph, specs/synthese). - website-data (nouveau), configure-nginx-proxy, docs DOMAINS_AND_PORTS README, features, fixKnowledge, userwallet features/docs.
27 lines
2.7 KiB
Markdown
27 lines
2.7 KiB
Markdown
# Website-skeleton: section connectée non affichée malgré pairing/relay OK
|
||
|
||
**Problème:** L'utilisateur voit dans UserWallet (HomeScreen) le statut « Pairing Satisfait: Oui » et « Statut réseau relais: OK », mais la page skeleton ne redirige pas vers la section connectée.
|
||
|
||
**Impacts:** L'utilisateur connecté (session existante) qui rafraîchit la page skeleton reste sur la section « Se connecter » au lieu de voir la section connectée.
|
||
|
||
**Cause:** La section connectée n’est affichée que si `canShowConnectedSection()` est vrai : session (login-proof) **et** dernier `pairing-relay-status` reçu avec `pairingSatisfied` et `relayOk`. Après un rafraîchissement, la session est en sessionStorage mais `pairingRelayStatus` n’est pas persisté. L’iframe UserWallet est dans un conteneur en `display: none` tant qu’on affiche la section login ; dans ce cas l’iframe peut ne pas charger (ou charger avec retard), donc le parent ne reçoit jamais `pairing-relay-status` et `pairingRelayStatus` reste `null`.
|
||
|
||
**Root cause:** Quand l’utilisateur a une session mais pas encore de `pairing-relay-status`, l’iframe est cachée donc elle ne charge pas (ou pas à temps) et n’envoie pas le message au parent.
|
||
|
||
**Correctifs:**
|
||
- Quand `isLoggedIn()` est vrai et `pairingRelayStatus === null`, afficher l’iframe (conteneur en `display: block`) pour qu’elle charge et envoie `pairing-relay-status`.
|
||
- Nouvelle branche dans `updateUI()` : `else if (isLoggedIn() && pairingRelayStatus === null)` → `showLoginInterfaceWithIframe(true)`.
|
||
- `showLoginInterfaceWithIframe(waitingForStatus)` : si `waitingForStatus` est vrai, afficher l’iframe et le message « Vérification du statut pairing et relais… » ; sinon comportement identique à `showLoginInterface()` (iframe cachée).
|
||
- Élément `#waiting-status` dans la section login, affiché uniquement en attente du statut.
|
||
|
||
**Evolutions:** Aucune.
|
||
|
||
**Pages affectées:**
|
||
- `website-skeleton/src/main.ts` (updateUI, showLoginInterfaceWithIframe, ref waitingStatusEl)
|
||
- `website-skeleton/index.html` (élément #waiting-status)
|
||
- `fixKnowledge/website-skeleton-section-connectee-non-affichee.md` (ce document)
|
||
|
||
**Modalités de déploiement:** Build et déploiement classique du website-skeleton.
|
||
|
||
**Modalités d’analyse:** 1) Se connecter sur le skeleton (login-proof reçu, section connectée affichée). 2) Rafraîchir la page : la section « Vérification du statut pairing et relais… » et l’iframe s’affichent brièvement, puis la section connectée s’affiche dès réception de `pairing-relay-status`. 3) Sans session : pas de changement (clic « Se connecter » puis login dans l’iframe pour obtenir la section connectée).
|