4nk/anchorage_layer_simple
5
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
anchorage_layer_simple/fixKnowledge/website-skeleton-section-connectee-non-affichee.md
ncantu f9fe0e3419 Website-skeleton partie connectée, contrat en dur, navigate-login; UserWallet pairing-relay-status, redirect; website-data, proxy data, cryptographie, fixKnowledge 
**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.
2026-01-29 00:55:58 +01:00

2.7 KiB
Raw Blame History

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).